Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiling a bool vector for an HVX target fails #4194

Open
steven-johnson opened this issue Aug 29, 2019 · 3 comments
Open

Compiling a bool vector for an HVX target fails #4194

steven-johnson opened this issue Aug 29, 2019 · 3 comments
Assignees

Comments

@steven-johnson
Copy link
Contributor

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
Copy link
Member

abadams commented Aug 29, 2019

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
Copy link
Contributor Author

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

steven-johnson added a commit that referenced this issue Aug 29, 2019
Work around bool-vector failure (Issue #4194)
@steven-johnson
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants