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

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

[sayantn]

However, even very old CPUs will have x87, right? So it seems like this will be enabled there?

Sorry, I forgot to mention that I am not sure if x87 should imply cpuid or not. I will edit and add an unresolved question.

And for SGX, this amounts to a promise that SGX will never support any target feature

Like, is it so inconceivable that SGX might get access to vector extensions one day?

I guess it's fine, the wikipedia page says

Both in the 11th and 12th generations of Intel Core processors, SGX is listed as "Deprecated"

Also, target features are supported to be additive, so not enabling any target features on sgx can't be problematic (I think, please correct me if I'm wrong).

I couldn't find much discussion of why it is a target feature in the first place.

The main rationale behind making it a target feature is target_feature_11, the cpuid intrinsic is safe to use for the overwhelming majority of usecases (at least sse enabled), but for the minority where it is not guaranteed support, it would be unsafe, and require explicit checking using is_x86_feature_detected!

[RalfJung]

Also, target features are supported to be additive, so not enabling any target features on sgx can't be problematic (I think, please correct me if I'm wrong).

It can be problematic if AVX in SGX becomes available and someone actually wants to use it. ;)

The main rationale behind making it a target feature is target_feature_11, the cpuid intrinsic is safe to use for the overwhelming majority of usecases (at least sse enabled), but for the minority where it is not guaranteed support, it would be unsafe, and require explicit checking using is_x86_feature_detected!

Technically it seems to be safe to use even without that feature gate.

[joshtriplett]

Our 32-bit targets are i586 and i686, and I don't think we should try to support older x86-32 CPUs without CPUID.

That leaves SGX. And that's enough of a special case that it seems like it should be its own thing, not a general-purpose target feature that implies code on x86 can't in general call CPUID with impunity.

[sayantn]

I don't think we should try to support older x86-32 CPUs without CPUID.

Ok in that case we can make __cpuid safe without the target feature. I think it might require a FCP, cc @Amanieu

[Amanieu]

I'm not 100% certain that CPUID is always guaranteed to be an innocuous opcode on pre-586 CPUs, including the various 386/486 clones. For those, there is a well-defined procedure for testing whether the CPUID instruction is supported.

On the other hand in #60123 we decided to effectively drop support for 386/486 by removing the explicit code to check for the presense of CPUID and instead assume it is always available. So far nobody has complained...

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