[PATCH] D77056: [Sema] Allow non-member operators for sizeless SVE types

[Richard Sandiford via Phabricator via cfe-commits]

rsandifo-arm added a comment.

In D77056#2487754 <https://reviews.llvm.org/D77056#2487754>, @rsmith wrote:

> In D77056#2465936 <https://reviews.llvm.org/D77056#2465936>, @rsandifo-arm wrote:
>
>> Either way, I realise this isn't great style.  It just seems like a practical compromise between the rock of classes having a constant size and the hard place of vectors having a variable length.
>
> I don't think this is just a question of style; it's a severe limitation to language functionality. In a very broad sense, you would not be able to use these types with templates. For example, even if you define an `operator<` between `svint8_t`, you can't use `std::min` between two `svint8_t`'s. And people are going to try to work around that by defining the operators first, then `#include`ing the algorithms in question, which will lead to ODR issues, will break when C++ modules is enabled, and so on.

I agree that, even after disallowing definitions in the global namespace, the feature could still be abused to cause ODR violations.  If that's a showstopper then I guess the patch can't go forward.  But it seems like the feature would have legitimate uses too.

> It's also a little unclear to me what the motivation for this is. Do you really want to permit (for example) an `operator+` between sizeless vectors that does something other than element-wise addition? If not, then why do we not instead directly provide built-in support for these operators, as we do for all our other vector types?

The aim of the patch is to allow SIMD frameworks like https://github.com/google/highway to be ported to SVE.

Most C++ SIMD wrappers are class based, using member functions (including member operator functions) for most operations.  `std::simd` is an obvious example of this.  This style of framework can't be ported to length-agnostic SVE because classes must be a constant size.  But frameworks like Highway instead use non-member functions and non-member operator overloads.  That approach is compatible with sizeless types.

We'd also like to maintain the current separation between the SIMD library and the underlying architecture support.  At it's heart, the SVE ACLE is just a set of low-level, machine-specific intrinsic functions.  t's not supposed to be a new generic language extension.

I agree the separation between the compiler and the library isn't too important for things like `operator+` on uniform types, since the operation only has one sensible implementation.  But some areas do provide an element of choice.  E.g.:

- Should `operator&` be defined for float vectors?
- Should `operator%` be implemented, even though it's not a native operation?
- What operators should be defined for `bfloat16_t` vectors?  At the moment, even scalar `bfloat16_t` supports very few “native” operations, but SIMD frameworks might want to provide more (now or in the future).
- Should `operator[]` be defined for `svbool_t`, and if so, what type should it return when applied to lvalues?
- Should mixtures of float and integer types be supported?

Leaving these decisions to the library means that the library can provide a consistent interface for multiple targets.  If we pick one behaviour for SVE, the library would need to pick the same behaviour for other vector architectures or force users to live with the inconsistency.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77056