Google should be compiling for the CPU baseline of the ABI their binaries are for, and then check if newer instructions are available before using them. Just like glibc and other projects do. The Debian documentation for this mentions tools to do this, like SIMDe and GCC/clang FMV.

https://wiki.debian.org/InstructionSelection

▲

wtallis 2 days ago | parent [-]

Am I missing something, or does SIMDe only help for cases where a program is using instruction intrinsics, and it doesn't do anything to address cases where the compiler decides to use SIMD as a result of auto-vectorization?

▲

pabs3 2 days ago | parent [-]

Thats correct, but usually compilers don't do that if you use the CPU baseline.

▲

wtallis a day ago | parent [-]

> but usually compilers don't do that if you use the CPU baseline

That's a problem that people are trying to solve by not using an ancient CPU baseline. Do you have a reasonable proposal for how else we should enable widespread use of hardware functionality that's less than two decades old?

	▲	pabs3 a day ago \| parent [-]
		The compiler could auto-enable function multi-versioning (FMV) for functions where auto-vectorisation gets triggered. At program start, FMV checks which instructions are available and updates function pointers to the right functions. Things like glibc use FMV to switch things like memcpy to SIMD-optimised versions.