* Björn Töpel:
For SVE, it is in fact disabled by default in the kernel. When a thread
executes the first SVE instruction, it will cause an exception, the kernel
will allocate memory for SVE state and enable TIF_SVE. Further use of SVE
instructions will proceed without exceptions. Although SVE is disabled by
default, it is enabled automatically. Since this is done automatically
during an exception handler, there is no opportunity for memory allocation
errors to be reported, as there are in the AMX case.
Glibc has an SVE optimized memcpy, right? Doesn't that mean that pretty
much all processes on an SVE capable system will enable SVE (lazily)? If
so, that's close to "enabled by default" (unless SVE is disabled system
wide).
Yes, see sysdeps/aarch64/multiarch/memcpy.c:
static inline __typeof (__redirect_memcpy) *
select_memcpy_ifunc (void)
{
INIT_ARCH ();
if (sve && HAVE_AARCH64_SVE_ASM)
{
if (IS_A64FX (midr))
return __memcpy_a64fx;
return __memcpy_sve;
}
if (IS_THUNDERX (midr))
return __memcpy_thunderx;
if (IS_THUNDERX2 (midr) || IS_THUNDERX2PA (midr))
return __memcpy_thunderx2;
if (IS_FALKOR (midr) || IS_PHECDA (midr))
return __memcpy_falkor;
return __memcpy_generic;
}
And the __memcpy_sve implementation actually uses SVE.
If there were a prctl to select the vector width and enable the vector
extension, we'd have to pick a width in glibc anyway.