X86_64-v2 and x86_64-v3 targets for Linux and Windows

GCC and LLVM appear to have agreed on x86_64 levels of instruction set extension bundles. The levels are defined in x86-64-ABI/low-level-sys-info.tex · master · x86 psABIs / x86-64 psABI · GitLab .

Future RHEL seems to be setting x86-64-v2 as its baseline.

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.)


I would love to see codegen support for these (and v4 as well), but I hope we don't need a different target spec just to provide optimized libraries.

As a first step, we need Rust to be using a version of LLVM that supports those architectures, and we need to have them work as codegen options.

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.

FWIW, everybody could read the pre-built latex as pdf here: https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/711608198/artifacts/raw/x86-64-ABI/abi.pdf?inline=false.


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.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.