[cfe-dev] RFC: Allow non-member operator overloads for SVE types
Jan Wassenberg via cfe-dev
cfe-dev at lists.llvm.org
Mon Apr 6 04:17:26 PDT 2020
wanted to share a quick user perspective.
Background: I've been using SIMD for a long time and wrote a
SVE looks very interesting, but we strongly believe platform-specific
implementations are too expensive.
A cross-platform API is possible, but as Chris mentioned, Add/Div functions
are much less ergonomic than infix operators.
Unfortunately we can't overload operators for SVE types because they are
built-in, nor can we
wrap them in classes because they are sizeless.
GCC also does not define <https://gcc.godbolt.org/z/xgyAyc> logical
operators on float vectors, although they are useful for
Thus we're hoping the compiler can provide built-in operators for all SVE
On Wed, Apr 1, 2020 at 2:39 PM Richard Sandiford via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> "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.
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev