Choosing between fixed-width NEON and length-agnostic SVE for portable AArch64 SIMD
0 reputation · 26 Nov 2020, 17:18 UTC
Goal: create a single AArch64 binary that runs on every ARMv8‑A CPU, using NEON when SVE is absent and automatically exploiting longer vectors on SVE‑capable cores without maintaining separate builds.
Constraints: GCC and Clang’s auto‑vectorizer may choose NEON, SVE, or a mixture depending on -march, -mtune, optimization level, data alignment, or OpenMP SIMD clauses, and there is no portable pragma or attribute that forces a specific SIMD backend across both compilers. SVE’s vector length is unknown at compile time, so code must rely on runtime capability checks (glibc HWCAP_SVE/HWCAP_SVE2 or the auxiliary vector) and length‑agnostic loops. On heterogeneous big.LITTLE systems SVE may be present only on some cores, requiring per‑CPU feature detection before launching SVE work.
- What compiler flags or attributes can reliably force NEON code generation in both GCC and Clang?
- Is there a portable way to request SVE code generation while providing a NEON fallback for older cores?
- How should a build system decide between a single fat binary with IFUNC selectors versus distributing separate NEON and SVE packages?