Add the cpuid target feature

[sayantn]

Tracking issue: #146558

r? @Amanieu

@rustbot label O-x86_32 O-x86_64 A-target-feature T-compiler T-libs-api

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

stdarch is developed in its own repository. If possible, consider making this change to rust-lang/stdarch instead.

cc @Amanieu, @folkertdev, @sayantn

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Amanieu]

This PR adds a new cpuid target feature which allows the use of the CPUID intrinsics in stdarch (implemented using inline asm). This doesn't have any codegen impact (it's not passed through to LLVM), but allows the CPUID intrinsics to be made safe using target features 1.1.

Since CPUID support is implicitly enabled on most of our x86 targets, this effectively makes the CPUID intrinsic safe to call even before the cpuid target feature is enabled, hence the FCP.

@rfcbot merge

[rust-rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @nikomatsakis
• @scottmcm
• @the8472
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[traviscross]

cc @RalfJung

[RalfJung]

I am a bit surprised to see this exposed as a target feature. The tracking issue says

• very old CPUs don't support it
• target_env = "sgx" doesn't support it

However, even very old CPUs will have x87, right? So it seems like this will be enabled there?
And for SGX, this amounts to a promise that SGX will never support any target feature. Is that truly a promise we can make?

Is the CPUID instruction actually unsafe in those situations? If it reliably segfaults, it would not be unsafe (as long as the inline asm block doesn't claim it will always return).

[joboet]

Is the CPUID instruction actually unsafe in those situations? If it reliably segfaults, it would not be unsafe (as long as the inline asm block doesn't claim it will always return).

The Intel reference says that

In earlier IA-32 processors that do not support the CPUID instruction, execution of the instruction results in an invalid opcode (#UD) exception being generated.

so yes, it will reliably abort the program. This could result in problems though if LLVM decides to add a cpuid intrinsic at some point if it assumes it to work unconditionally...

On SGX, cpuid is supported, but the results cannot be trusted so it should not be used in most cases.

[RalfJung]

This could result in problems though if LLVM decides to add a cpuid intrinsic at some point if it assumes it to work unconditionally...

LLVM is not involved here at all, cpuid is proposed as a Rust-only target feature.

[joboet]

This could result in problems though if LLVM decides to add a cpuid intrinsic at some point if it assumes it to work unconditionally...

LLVM is not involved here at all, cpuid is proposed as a Rust-only target feature.

[RalfJung]

I don't think hypothetical future LLVM extensions are that relevant here. Even if that happens, we can just keep using the inline asm version.

On SGX, cpuid is supported, but the results cannot be trusted so it should not be used in most cases.

Hm, interesting. I don't think we have used target features for "should not be used" before. Also this does not resolve the problem of "what if we ever want to enable any of the other target features (that imply cpuid) in SGX". Like, is it so inconceivable that SGX might get access to vector extensions one day?

To be clear, I don't have a strong opinion either way, this just feels like an "odd" target feature and I couldn't find much discussion of why it is a target feature in the first place.