C++ backend doesn't handle float16/bfloat16 correctly #4916
Comments
steven-johnson
added a commit
that referenced
this issue
Apr 17, 2022
Fixes issues #3709, #3967, #4916. I think this is the meaningful remaining bits (outside of Python) that have been left unanswered for a while. Note the addition of `halide_float16_t` and `halide_bfloat16_t` in HalideRuntime.h as runtime placeholders that are equivalent to the language-only variants in Float16.h. Note that there are similar issues in the Python bindings, but I'm going to land those in a subsequent PR to minimize confusion.
steven-johnson
added a commit
that referenced
this issue
Apr 19, 2022
Fixes issues #3709, #3967, #4916. I think this is the meaningful remaining bits (outside of Python) that have been left unanswered for a while. Note the addition of `halide_float16_t` and `halide_bfloat16_t` in HalideRuntime.h as runtime placeholders that are equivalent to the language-only variants in Float16.h. Note that there are similar issues in the Python bindings, but I'm going to land those in a subsequent PR to minimize confusion.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It emits code that assumes that
float16_tandbfloat16_talready exist, and can interoperate directly with other C++ numeric types (via cast, operators, etc), which isn't true, thus the resulting code won't compile.(Note we have code to do most of this in Float16.h/.cpp but that is compile-time only, and not currently visible to runtime code.)
The text was updated successfully, but these errors were encountered: