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.

[joshtriplett]

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

Right, exactly. If we had a target that ran on i386 or i486, then it should do CPUID detection. But if you're on i586 or i686, CPUID is always supported, by definition of the target.

[tmandry]

@rfcbot reviewed

[nikomatsakis]

@rfcbot reviewed

[joshtriplett]

Being explicit: not raising any blocking objection to the strategy of using target features to make cpuid safe, but I think it's a mistake to not just have cpuid safe everywhere it's available, and make it entirely unavailable on a hypothetical i386/i486 target.

I don't think unsafe is a good way to represent SGX's issue of "you can't count on this as meeting sandbox guarantees". It won't actually cause UB, as far as I understand.

[scottmcm]

I feel very strongly that "should not be used" or "gives untrusted result" is not a reason to make it unsafe.

(Exactly what to do here I don't know that I have an opinion yet.)

---

I'll also add that old x86 has a bunch of semantic problems too, like broken floating point, so anything pre-sse is already not "really" a tier 1 target -- maybe not even really a tier 2 one since lots of things just don't work reliably.

[joshtriplett]

We talked about this again in today's @rust-lang/lang meeting.

Reiterating that this is not blocking, and if others want to do this with target features, so be it. I don't plan to check a box but I don't intend to raise a concern.

That said, counterproposal: rather than a target feature, can we transition to cpuid being universally safe (using the mechanisms we normally use to move something from unsafe to safe without provoking widespread warnings about unused unsafe)?

[sayantn]

To address the counterproposal of making cpuid universally safe, raised by quite a few people here, I can open a PR in stdarch repo, and start a libs-api and lang FCP there. Then we can decide between the two approaches by seeing which FCP actually gets accepted (I have the feeling that people are very reluctantly accepting the FCP, even though they like the counterproposal better). Does that sound good?

[traviscross]

It sounds good to me. In the lang call today, our general vibe was indeed not positive on the proposal in this PR, and as it stands, I estimate this proposed FCP will struggle.

[sayantn]

I have opened rust-lang/stdarch#1935 to make cpuid safe without any target features, let's rfc on that

[the8472]

and make it entirely unavailable on a hypothetical i386/i486 target.

An i486 target can check if the ID bit in the EFLAGS register can be toggled and use that to feature-detect cpuid support.
So cpuid is conditionally-available on i486 and runtime-detectable. Which suggests it's a target-feature.

Ah yes, core_arch already implements has_cpuid

[sayantn]

Ah yes, core_arch already implements has_cpuid

it did, but then it was removed. I can't remember the rationale exactly. The link seems pretty old, it was removed like an year ago.

[bors]

☔ The latest upstream changes (presumably #148356) made this pull request unmergeable. Please resolve the merge conflicts.

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

[bors]

☔ The latest upstream changes (presumably #147645) made this pull request unmergeable. Please resolve the merge conflicts.

[sayantn]

As the fcp on rust-lang/stdarch#1935 has completed, I am closing this

[jethrogb]

I just want to clarify that contrary to some of the claims earlier in this thread, SGX doesn't support CPUID, calling the instruction results in an #UD exception.