Re: [PATCH] libstdc++: add ARM SVE support to std::experimental::simd

[Matthias Kretz <m.kretz@gsi.de>]

On Thursday, 4 January 2024 10:10:12 CET Andrew Pinski wrote:
> I really doubt this would work in the end. Because HW which is 128bits
> only, can't support -msve-vector-bits=2048 . I am thinking
> std::experimental::simd is not the right way of supporting this.
> Really the route the standard should be heading towards is non
> constant at compile time sized vectors instead and then you could use
> the constant sized ones to emulate the Variable length ones.

I don't follow. "non-constant at compile time sized vectors" implies 
sizeless (no constexpr sizeof), no?
Let me try to explain where I'm coming from. One of the motivating use 
cases for simd types is composition. Like this:

template <typename T>
struct Point
{
  T x, y, z;

  T distance_to_origin() {
    return sqrt(x * x + y * y + z * z);
  }
};

Point<float> is one point in 3D space, Point<simd<float>> stores multiple 
points in 3D space and can work on them in parallel.

This implies that simd<T> must have a sizeof. C++ is unlikely to get 
sizeless types (the discussions were long, there were many papers, ...). 
Should sizeless types in C++ ever happen, then composition is likely going 
to be constrained to the last data member.

With the above as our design constraints, SVE at first seems to be a bad 
fit for implementing std::simd. However, if (at least initially) we accept 
the need for different binaries for different SVE implementations, then you 
can look at the "scalable" part of SVE as an efficient way of reducing the 
number of opcodes necessary for supporting all kinds of different vector 
lengths. But otherwise you can treat it as fixed-size registers - which it 
is for a given CPU. In the case of a multi-CPU shared-memory system (e.g. 
RDMA between different ARM implementations) all you need is a different 
name for incompatible types. So std::simd<float> on SVE256 must have a 
different name on SVE512. Same for std::simd<float, 8> (which is currently 
not the case with Sriniva's patch, I think, and needs to be resolved).

> I think we should not depend on __ARM_FEATURE_SVE_BITS being set here
> and being meanful in any way.

I'd love to. In the same way I'd love to *not depend* on __AVX__, 
__AVX512F__ etc.

- Matthias

-- 
──────────────────────────────────────────────────────────────────────────
 Dr. Matthias Kretz                           https://mattkretz.github.io
 GSI Helmholtz Center for Heavy Ion Research               https://gsi.de
 std::simd
──────────────────────────────────────────────────────────────────────────