| > Also, let's stop with the "vector length agnostic" types being the sole option for SVE extensions They aren't, see the `arm_sve_vector_bits` attribute. > I'm fine with recompiling my code, I do it every day Then you can do that. > If I have an algorithm that's truly vector length agnostic, I can make the vector length a constant in my code that can change based on the compile target. You can do that, but why not simply write it in a vector-length-agnostic way? IMO the better approach is to start thinking about SIMD optimizations in a VLA way, and specialize on the vector length, when that becomes advantageous.
Doing it this way is better even if you end up not writing VLA code, because you though about the scalability problem. Many libraries currently don't scale beyond 128-bit, not because they couldn't make efficient use of >128-bit, but because the library was architect around 128-bit and changing that amounts to almost a full rewrite. So now you are stuck wasting 3/4th of your ALUs running 128-bit SSE on Zen5. |