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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
