You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The failure is of the form Codegen of Expr (t1142 > x64((uint32)65535)) of type uint1x64 did not produce llvm IR of the corresponding llvm type.
This appears to be an injection from the recent bfloat16 PR... though it seems that the type mismatch may have always been present (but harmless/unnoticed), as the type check that is firing is new.
Aside from the fact that we need to fix this, it's also clear that the bool-vector transmutation code is undertested in Halide, as this wasn't noticed until an attempt at integration into Google.
(I'm working on getting a simple standalone repro case, will update when I have one)
The text was updated successfully, but these errors were encountered:
I think llvm_type_of (which is now virtual) needs adjusting in codegen_hexagon. Dillon, is the result of a comparison just always an 8-bit mask, or does it vary according to the args? The latter might be difficult to handle, because there's no one llvm type corresponding to the Halide type. If so we may just need to neuter the assertion for bool vectors.
The failure is of the form
Codegen of Expr (t1142 > x64((uint32)65535)) of type uint1x64 did not produce llvm IR of the corresponding llvm type.
This appears to be an injection from the recent bfloat16 PR... though it seems that the type mismatch may have always been present (but harmless/unnoticed), as the type check that is firing is new.
Aside from the fact that we need to fix this, it's also clear that the bool-vector transmutation code is undertested in Halide, as this wasn't noticed until an attempt at integration into Google.
(I'm working on getting a simple standalone repro case, will update when I have one)
The text was updated successfully, but these errors were encountered: