[PATCH] D85009: [Sema][BFloat] Forbid arithmetic on vectors of bfloat.

[Simon Tatham via Phabricator via cfe-commits]

simon_tatham added a comment.

In D85009#2187643 <https://reviews.llvm.org/D85009#2187643>, @jfb wrote:

> Language-wise I think https://wg21.link/p1467 is where C++ is going, and C is taking a similar approach.

That doesn't seem to mention vectors at all. As I said on Friday, I wouldn't disagree with the idea that //scalar// bfloat should have consistent semantics across compiler targets.

> I'd like to make sure this is well thought out. Not just "the ISA does this, let's do the same". We know other ISAs act differently, and I'm not clear on what the intended behavior will be for people writing C and C++ code.

But C-language bindings for vector subsystems have //always// been strongly tied to the capabilities of the ISA. You enable them in the first place by including some target-specific header such as `arm_neon.h` or `wmmintrin.h` or what have you, and then the available operations are whatever are defined by the organization that specified that header.

In this case, `bfloat16x4_t` and `bfloat16x8_t` are type names defined in `arm_neon.h`. That header is defined by Arm (in the ACLE spec), and you only include it and use its definitions if you know you're targeting the Arm ISA. So it makes sense that the available operations should correspond to the things you can do efficiently on that ISA.

If you wanted //cross-platform// vector bfloat code, you'd include some other header that nobody has defined yet. Or, more likely, you'd just write scalar bfloat source code, and rely on the compiler to vectorise it for each target.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85009