Compiling a bool vector for an HVX target fails

[steven-johnson]

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)

[abadams]

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.

[steven-johnson]

It varies according to the type; in EliminateBoolVectors, we use signed ints of the same width as the types being compared.

[steven-johnson]

Checked in a workaround, but leaving this open, as a better fix (and better tests) are needed.