Optimize has_cpuid for x86 targets with know support

[gnzlbg]

For example, we could check if the x86 target has mmx support and return true unconditionally if that's the case.

[stevecheckoway]

I'm not sure mmx is the correct feature to check for. One can compile for, for example,

{
  "llvm-target": "i686-unknown-none",
  "features": "-mmx"
  ...
}

But its presence is certainly sufficient.

If I'm reading this correctly (and I'm just poking around for the first time now), there are a whole bunch of features that are available. I'm not sure which features are exposed, but perhaps one could check for the presence of at least one of a set of them that imply cpuid support.

[gnzlbg]

I'd prefer to keep this simple, this is all best effort anyways.

IIRC Rust's i586 targets have sse enabled, and i686 targets have sse2 enabled. So if we just detect sse at compile-time for the x86 arch that gets us 99% there for most supported targets.

For all others... unless the user is calling has_cpuid manually (e.g. in a #[no_std] crate), the has_cpuid function is invoked as part of run-time feature detection (std::__detect) at most once per process (its result is cached)...

If #[no_std] crates really care about this I would be fine with just saying that they should cache the result, and any run-time feature detection library for #[no_std] crates should already be doing this anyways.

We should strongly encourage #[no_std] crates to not do run-time feature detection themselves but to choose a run-time feature detection libraries that suits their target domain.

[gnzlbg]

So i've just sent a PR that just tests for SSE and returns true if that's enabled at compile-time. Should just work for all i586 rust targets and upwards, but for non Rust targets we can probably do better.

I am leaving this open and changing difficulty to hard because PRs that improve on this are welcomed, but getting it "really right" isn't trivial.