The name __bfloat may mislead its real type is bfloat16, but in
fact it's not.
Details
- Reviewers
pengfei LuoYuanke craig.topper skan
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
clang/lib/Headers/avx512vlbf16intrin.h | ||
---|---|---|
416 | I'm not sure if this change is a good idea this late. Users could have been dependent on it being an unsigned value before. I believe this changes the behavior of this code int result = _mm_cvtness_sbh(X) Previously it would have zero extended, but now it will sign extend. |
clang/lib/Headers/avx512vlbf16intrin.h | ||
---|---|---|
416 | Yes, this should be a huge concern. Notice that intrinsic update has just documented these two intrinsics on 12/7/2021. So maybe we still have change to change it? And it's more theory right to do sign extension from a bfloat16 to int32. |
clang/lib/Headers/avx512vlbf16intrin.h | ||
---|---|---|
416 | I think this is the problem that we choose integer to represent BF16. Neither zero extend nor sign extend makes sense to a floating type. But considering the MSB of floating point is sign bit. Sign extend should be better in theory. |
clang/lib/Headers/avx512vlbf16intrin.h | ||
---|---|---|
416 | Sorry, I mean unsigned short |
clang/lib/Headers/avx512vlbf16intrin.h | ||
---|---|---|
416 | I'm fine with just changing it to unsigned short |
I would suggest we drop the change. Sorry for my fickleness :(
clang/lib/Headers/avx512bf16intrin.h | ||
---|---|---|
32 | Sorry, when I reviewed the doxygen, I found a new problem. If we want to use unsigned short, we may need to change here too. But unsigned short is not clear to user since they actually want to convert a bfloat type instead of integer. |
Sorry, when I reviewed the doxygen, I found a new problem. If we want to use unsigned short, we may need to change here too. But unsigned short is not clear to user since they actually want to convert a bfloat type instead of integer.
On the other hand, the double underscore naming conversion is reserved for compiler use and we have already used lots of these terminologies for X86 intrinsics. A much similar one is __mask16. So I think using __bfloat16 here is consistent with the existing types we have defined.