CPU Features

CPU features

Programs are compiled for the generic target of their architecture: x86-64 with SSE2, or ARMv8.0 with NEON on arm64. The runtime does not assume anything beyond that. It asks the CPU once, when the first part of it needs the answer (cpuid and xgetbv on x86, which also makes sure the operating system saves the wide registers; getauxval on arm64 Linux, sysctl on macOS and IsProcessorFeaturePresent on arm64 Windows), and code that is faster with an optional instruction set only runs when the CPU has it.

BLITZLLVM_CPU lowers the result, which is how each of those code paths is tested without owning every CPU. It never adds a feature the CPU does not have. It holds a list, separated by commas:

Setting	Effect
baseline	No optional features: SSE2 only on x86-64, NEON only on arm64.
v2, v3, v4	x86-64 only: at most the features of the x86-64-v2, -v3 or -v4 microarchitecture level (v4 is AVX-512).
native	What the CPU has. This is the default.
-<feature>	Removes a feature and everything that needs it, such as -avx2, -fma, -sse4.1, -dotprod or -sve2.

For example BLITZLLVM_CPU=v3,-fma runs as an AVX2 machine without FMA. A program started with --profile and BLITZ_FPS=1 prints the result as cpu: x86_64 v3: sse3 ssse3 ... before the first frame report. Which features are used, and where, can differ between versions.

Code that has versions for several instruction sets always has a plain version that is the specification, and every other version gives the same bytes (or the same bits for floats, which are never fused into a multiply-add there). The tests run each version against the plain one under each BLITZLLVM_CPU setting. At the moment LockBuffer and UnlockBuffer swap the red and blue channels of 32 bit buffers this way (SSSE3 and AVX2 on x86-64, NEON on arm64).