On Wednesday, 27 March 2024 11:07:14 CET Richard Sandiford wrote: > I'm still worried about: > > #if _GLIBCXX_SIMD_HAVE_SVE > constexpr inline int __sve_vectorized_size_bytes = __ARM_FEATURE_SVE_BITS > / 8; #else > constexpr inline int __sve_vectorized_size_bytes = 0; > #endif > > and the direct use __ARM_FEATURE_SVE_BITS elsewhere, for the reasons > discussed here (including possible ODR problems): > > https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640037.html > https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643734.html > > Logically the vector length should be a template parameter rather than > an invariant. Has this been resolved? If not, it feels like a blocker > to me (sorry). The vector length is always a template parameter to all user-facing API. Some examples 1. on aarch64 the following is independent of SVE flags (and status quo): simd is an alias for simd fixed_size_simd is supposed to be ABI-stable anyway (passed via the stack, alignof == sizeof). 2. with -msve-vector-bits=512: native_simd is an alias for simd> simd> is an alias for simd> 3. with -msve-vector-bits=256: native_simd is an alias for simd> simd> is an alias for simd> Implementation functions are either [[gnu::always_inline]] or tagged with the ABI tag type and the __odr_helper template argument (to ensure not-inlined inline functions have unique names). Does that make __ARM_FEATURE_SVE_BITS usage indirect enough? Also for context, please consider that this is std::*experimental*::simd. The underlying ISO document will likely get retracted at some point and the whole API and implementation (hopefully) superseded by C++26. The main purpose of the spec and implementation is to gather experience. Best, Matthias -- ────────────────────────────────────────────────────────────────────────── Dr. Matthias Kretz https://mattkretz.github.io GSI Helmholtz Center for Heavy Ion Research https://gsi.de std::simd ──────────────────────────────────────────────────────────────────────────