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

[Jan Wassenberg via cfe-dev]

Hi,
wanted to share a quick user perspective.
Background: I've been using SIMD for a long time and wrote a
performance-portable
wrapper <https://github.com/google/highway>.

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
abs/signbit/copysign.

Thus we're hoping the compiler can provide built-in operators for all SVE
types.

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.
>
> Thanks,
> Richard
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200406/a38a63eb/attachment.html>