is_x86_feature_detected! (and its friends) will simply compile to
true if a feature is enabled at compile time, instead of actually checking if a feature is available at runtime.
This means that you can't have a program where you enable extra CPU features for the build and then check your assumptions at the start of the program and print a nice error message to the user if their CPU doesn't fit your assumptions.
I think we should support that sort of thing, so I think that we need an "actually really check for this feature at runtime" ability.
This might be a nice mitigation for some programs, but since e.g. enabling AVX will let LLVM use AVX all over the code for small-ish memcpys, it's generally only useful if done immediately at the start of
main(). This is specific enough that I don't think it should be tied to
is_x86_feature_detected, it should be a separate function for this specific use case only.
I would absolutely agree. It should be stand alone.
If it were to eventually be in libstd, probably the best way would be to expose the "backend" of the macro that does the runtime checking, and then the macro would continue to wrap it all up in a
cfg!(target_feature="foo") || runtime_check("foo") type of deal.
In the general case, I would expect a program compiled with such support enabled to potentially attempt to use that support before main, or for that matter in the course of calling ordinary functions, unpredictably.
So even checking at the top of main may not suffice.
I think @gnzlbg had a issue or thread about automatically doing this (and maybe e.g. panicking or whatever if the feature set doesn't match)
What about intrinsics?
Can we not use avx intrinsics without compiling everything with avx enabled? (and then guard those with a runtime check)
Uh, right. To back up a bit and give a little background:
core::arch exposes all intrinsics as
unsafe functions without you needing to enable the feature at compile time. It's up to you to come up with a system of making the unsafe safe.
The second option is "simpler", but also now your program expects a minimum CPU to run, and both Rust and most operating systems lack a way to mark a binary with what CPU features it needs, so there's no easy way to give a message if the current CPU is missing a feature you expected. Instead the user runs a program that looks like a normal program, and they get a mysterious crash.