Make cpuid safe and update docs

[sayantn]

Counterproposal to rust-lang/rust#146560

This makes __cpuid, __cpuid_count and __get_cpuid_max safe to use. All of these just call the CPUID instruction, so it is safe to call whenever the CPUID instruction is available (it has defined behavior even if unsupported leaf values are passes). There are cases when it might not be available

• processors lower than i386, which afaik rust doesn't support anymore. The has_cpuid function was removed with this exact motivation, and it is justified
• SGX environments can't use CPUID. Or more accurately, they can't trust the output of CPUID. It should also be mentioned that SGX has been deprecated by intel for quite some time now.

As these are very niche cases we propose to make cpuid safe in general.

Alternatives

Leave it unsafe

This is always an option. But for most use cases using __cpuid is perfectly safe, so it is inconvenient (and more so for projects that ban uses of unsafe).

Introduce a cpuid target feature, and take advantage of target_feature_11

This is what rust-lang/rust#146560 does. As all X86 target features (other than soft_float and x87) were introduced after CPUID, we can add a detection-only target feature cpuid that is implied by all X86 target features. This makes using it in i686 or x86_64 targets safe due to sse being auto-enabled in the targe description, whereas i386 remains unsafe as it doesn't enable sse

[rustbot]

r? @folkertdev

rustbot has assigned @folkertdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[traviscross]

Proposing FCP on this (in fact, even nominating it) is blocked on:

• Prepare for lang FCPs in stdarch team#2007

[traviscross]

@sayantn, if you could please update the PR description with the details of the stabilization being proposed, the motivation, etc., that would be helpful to us in considering this nomination and for proposing FCP.

[joshtriplett]

👍 for this. One clarification:

processors lower than i386

For the avoidance of ambiguity: lower than i586, which is lower than the current 32-bit x86 targets in Rust.

[traviscross]

Thanks @sayantn. Le'ts propose to do it.

@rfcbot fcp merge

[rust-rfcbot]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @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.

[tmandry]

We discussed this in the lang team meeting today and the agreement was that if we add support for an older target like i586, we can make this unsafe and require target_feature for the intrinsic on that target. These intrinsics are already platform-specific, so it's natural to have a more target-specific definition that changes the safety of the intrinsic.

@rfcbot reviewed

[nikomatsakis]

@rfcbot reviewed