[PATCH] D120395: [X86] Prohibit arithmetic operations on type `__bfloat16`

Thu Mar 3 23:59:13 PST 2022

pengfei added a comment.

> if we define the `__bfloat16` type as the built-in `__bf16` type, then the front end can apply whatever rules it has for that type, including adding whatever ABI handling is needed for BF16 values.

I don't agree. Unlike `__fp16`, `__bf16` is simple an ARM specific type. I don't see why we need to define with it. https://clang.llvm.org/docs/LanguageExtensions.html#half-precision-floating-point . Besides, the doc says it "is only available when supported in hardware". Since we only have vector instructions, I don't think we support the scalar type here.

> If that ends up being the same as the rules for unsigned short, that's no problem. The front end can implement it that way.

Doesn't it mean front end still generate `i16` in IR for it?

> The point is, by telling the front end that this is a BF16 value, we allow the front end to control the semantics for it.

If you are saying we support a separate `__bfloat16` type in front end and generate `i16` in IR just for doing diagnose, I'm fine with it. The problem is we can't reuse the `__bf16` 's representation `BFloat16Ty`. Instead, we have to follow the way we are using for fp16, e.g., `HalfTy` for `__fp16` (no ABI) and `Float16Ty` for `_Float16` (has ABI). But it doesn't worth the effort to me.

> Also, you say we can't assume what registers will be used (in the eventual ABI?) but we are assuming exactly that. If the ABI is ever defined differently than what clang and gcc are currently doing, they will both be wrong.

No new IR types, no ABI issues. The declaration of double underscore type are free without ABI. `__fp16` is a good example: https://godbolt.org/z/6qKqGc6Gj

> I don't see why we would treat BF16 values as unsigned short and i16 throughout the compiler just to make the backend implementation easier when we already have types available for BF16.

So, it is not a problem of easy or difficult. It's a wrong direction we can't go with it (introducing new IR type without clear ABI declarations). We made such mistake with the `half` type. https://godbolt.org/z/K55s5zqPG We shouldn't make it again.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120395/new/

https://reviews.llvm.org/D120395