[cfe-dev] RFC: Allow non-member operator overloads for SVE types

[Richard Sandiford via cfe-dev]

"Keane, Erich via cfe-dev" <cfe-dev at lists.llvm.org> writes:
>> Before I say anything, I'd like to mention that I am generally in
>> favor of having arithmetic operators defined for vector types.
>
> For the rest of 'vector' types, we would almost definitely want to
> implement the operators in clang directly rather than allowing
> overloading.  While I appreciate the attractiveness of operator
> overloads on these types, it would be implementation divergence from
> GCC. (ICC Interestingly chose the alternate direction).

Yeah, this isn't something I would suggest for normal vector types.
With those, anyone who wants to provide their own operators can wrap
the vector in a class.

SVE types like __SVInt8_t are different because, at the semantic level,
they aren't vector types in the way that clang and GCC understand them.
They're instead just opaque blobs of unspecified size that are manipulated
via intrinsic functions.  Their vectorness only becomes apparent during
code generation.

So clang and GCC are consistent in not providing built-in operators
for __SVInt8_t & co.  (I'm not sure you were suggesting otherwise,
I just wanted to clarify.)

GCC has an -msve-vector-bits=N option that lets you specify the
number of bits in an SVE register.  When this is used, types like
__SVInt8_t remain opaque types of unspecified size, to ensure that
the types have the same semantic identity regardless of whether the
vector size is known at compile time.  But GCC does allow implicit
conversion between these sizeless types and "normal" fixed-length
vectors of an appropriate type and size, such as those created by
__attribute__((vector_size(N/8))).  This makes it possible to use
normal fixed-length vectors with SVE intrinsics.  We're planning
to support this for clang too.

The proposal here would only affect opaque not-really-vector types
like __SVInt8_t.  Normal N-bit vectors would be unaffected and
would continue to use the built-in operators.

Similarly, if in future clang and/or GCC supported a truly
cross-platform variable-length vector extension as part of the
core language, it would probably make sense to allow implicit
conversion between those cross-platform types and the corresponding
opaque SVE types.  Here too I imagine the cross-platform types would
use built-in operators.

Thanks,
Richard