"haswell" is currently defined as:
if (platform == NULL
&& CPU_FEATURES_ARCH_P (cpu_features, AVX2_Usable)
&& CPU_FEATURES_ARCH_P (cpu_features, FMA_Usable)
&& CPU_FEATURES_CPU_P (cpu_features, BMI1)
&& CPU_FEATURES_CPU_P (cpu_features, BMI2)
&& CPU_FEATURES_CPU_P (cpu_features, LZCNT)
&& CPU_FEATURES_CPU_P (cpu_features, MOVBE)
&& CPU_FEATURES_CPU_P (cpu_features, POPCNT))
platform = "haswell";
XSAVE, FXSR, MMX, SSE2 are probably implied.
On the GCC side, -march=haswell also has AES, RDRND, PCLMUL, XSAVEOPT, SSE3, SSE4_1, SSE4_2, SSSE3, HLE, F16C, FSGSBASE, CMPXCHG16B.
I think the glibc and GCC definitions need to be consistent.
IMHO adding "haswell" was a mistake (with this particular name). Do we really
want to have gazillions of $arch directories to be searched, and in what
particular order if an "exact match" (define that!) is not found? That's
especially difficult with Intels segmentation of SKUs where there's not
a clear ordering of architectures is possible if an exact match is not found.
I agree that "haswell" suggests you can put in -march=haswell binaries
(which you can't as you point out).
The directory should have been named avx2_fma_bmi12_lzcnt_movbe_popcnt.
Or rather binaries/libraries should use ifunc relocations because x86 is a mess.
Somewhat relevant discussion: <https://sourceware.org/pipermail/libc-alpha/2020-May/113757.html>
Fixes to "haswell" (under whatever name) would probably come under that new umbrella, with the existing selection remaining unchanged (until it is deprecated and then removed).
I consider this fixed by:
Author: Florian Weimer <firstname.lastname@example.org>
Date: Fri Dec 4 09:13:43 2020 +0100
x86_64: Add glibc-hwcaps support
The subdirectories match those in the x86-64 psABI:
Reviewed-by: Adhemerval Zanella <email@example.com>
“x86-64-v3” is more or less a replacement for the “haswell” AT_PLATFORM subdirectory.