What's the current thinking on making rustc recognize these and distributing pre-built standard library as Linux and Windows targets? (That is, x86_64_v2-unknown-linux-gnu and so on.)
(On Mac, Rust currently aligns to the features of the oldest CPU capable of running Lion. It would probably make sense to provide another target that covers the CPU with the fewest extensions that a newer still-supported macOS release runs on.)
Some things in the newer instruction set extensions are in inlines in the standard library, so e.g. to benefit from POPCNT in application code, a different pre-built standard library isn't needed.
However, I gather that x86-64-v2 as the target would make 128-bit atomics available. (Aside: I gather than Windows 10 requires 128-bit atomics to be always available.) Beyond that, it's unclear to me what exactly the levels would do to the non-inline parts of the standard library itself.
These levels seem mostly related to which target features are available. I'd think we can support this through the existing mechanisms for target features in combination with cargo-aware std for (re)building std with target-specific optimizations.
I filed an issue about recognizing these as target_cpu. Considering the number of combinations, it indeed seems like having cargo build std locally is the best way forward on the std side.