Stabilize the x86 has_cpuid intrinsic

[gnzlbg]

Summary

This PR stabilizes the x86 has_cpuid intrinsic.

Motivation

#[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
fn has_cpuid() -> bool;

returns true if the CPU supports the CPUID instruction, and false otherwise.

This intrinsic is useful for implementing run-time feature detection that is able to properly handle i386 CPUs and older (we have some Rust targets for these, e.g., i386-apple-ios). Some users, like @briansmith here, want to tune how run-time feature detection works, which is sometimes a reasonable thing to do both for std and #![no_std] targets. We provide the std::detect module also as a std_detect crate on crates.io which has some extra cargo features that users can customize to tailor run-time feature detection to their application without having to create a new Rust target for it.

User and reference level information

The intrinsic API is very simple, the doc comment just states "Does the host support the CPUID instruction?", and the type of the intrinsic is a fn() -> bool that answers this question.

Implementation details

The inline comments explain the implementation; it just follows the Intel and OSDEV: detecting CPUID availability documentation.

This intrinsic returns true as a compile-time constant when it can infer the answer from cfg(target_arch) or cfg(target_feature), and only performs a run-time computation when this is not the case.

Prior art

Both clang and gcc implement this logic, although they do not expose it as its own separate intrinsic.

Alternatives

We could not expose this intrinsic, but that would require people writing their own run-time detection frameworks, e.g., for #![no_std], to use inline assembly instead to query this information.

API-wise, I can't think of a different type-signature for this intrinsic.

cc @rust-lang-nursery/libs @rust-lang/libs

[gnzlbg]

cc @Amanieu it seems that I can't ping the rust-lang/libs team from the nursery =/

[alexcrichton]

I don't think rfcbot works here, but @gnzlbg mind opening a tracking issue on rust-lang/rust with this stabilization report so we can FCP?

[gnzlbg]

@alexcrichton done: rust-lang/rust#60123

[bjorn3]

rust-lang/rust#60123 has been closed. I believe the consensus was to not stabilize this.

[gnzlbg]

Thanks!