andrew.w.kaylor added a comment. In D120395#3340953 <https://reviews.llvm.org/D120395#3340953>, @craig.topper wrote:
> These intrinsics pre-date the existence of the bfloat type in LLVM. To use > bfloat we have to make __bf16 a legal type in C. This means we need to > support loads, stores, and arguments of that type. I think that would create > bunch of backend complexity because we don't have could 16-bit load/store > support to XMM registers. I think we only have load that inserts into a > specific element. It's doable, but I'm not sure what we gain from it. My motivation for wanting to use 'bloat' started with wanting to use '__bf16' as the front end type. It just doesn't make sense to me to define a new type when we have an existing built-in type that has the same semantics and binary representation. The argument for introducing a new IR type was made here: https://reviews.llvm.org/D76077 It doesn't seem like a particularly strong argument, but it's what was decided then. Using bfloat rather than i16 in the IR has the benefit that it expresses what the type actually is instead of just using something that has the same size. Using i16, the semantics of the type are known only to the front end and we have to rely on what the front end did for enforcement of the semantics. That's generally going to be OK, but it seems to me like it works for the wrong reason. That is, i16 is not a storage-only type and the only reason we don't notice is that the front end doesn't generate IR that violates the implicit semantics of the type. I think there's a minor argument to be made concerning TBAA (short and __bfloat16 look like compatible types). Perhaps a more significant argument is that using the __bf16 built-in type would allow us to define a type like __m256bh like this: typedef __bf16 __m256bh __attribute__((__vector_size__(32), __aligned__(32))); So my question would be, how much work are we talking about to make this work with the x86 backend? 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
