cpufeatures: requesting (minimal) miri support

[jrose-signal]

miri doesn't support inline assembly, including cpuid. But cpufeatures could treat it like it does SGX: if a target feature isn't on at compile time, it's not available at run time.

[jrose-signal]

Hang on, this is within my capabilities to send you a pull request. :-)

[tarcieri]

I'm curious about the use case for your suggested solution: won't code which actually uses any enabled features fail to compile under miri? And if so, shouldn't it always default to those features being unavailable?

[jrose-signal]

That is a good point. I hadn't actually tested with, e.g. -C target-cpu=native, and I do get a failure along those lines:

error: unsupported operation: can't call foreign function: llvm.x86.aesni.aesimc
    --> /Users/jordan/.rustup/toolchains/nightly-2022-06-22-x86_64-apple-darwin/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/x86/aes.rs:83:5
     |
83   |     aesimc(a)
     |     ^^^^^^^^^ can't call foreign function: llvm.x86.aesni.aesimc
     |
     = help: this is likely not a bug in the program; it indicates that the program performed an operation that the interpreter does not support

However, that isn't something that's inherently true; miri can implement support for particular intrinsics even if it (probably?) can't support arbitrary inline assembly. (It supports the portable SIMD APIs, for example.) So I think it's still useful to allow explicitly-set target features. (I'm not a miri expert, though; I'm drawing this mostly from previous discussion around is_x86_feature_detected!())

[tarcieri]

Relevant issue: rust-lang/const-eval#7

The proposed solution is detecting miri is in use and falling back to a portable miri-friendly implementation. We could potentially do just that with cpufeatures

[jrose-signal]

I mean, that's what clients of cpufeatures should do, right? cpufeatures itself should either believe the compiler (my PR), or just say false unless we specifically know miri supports a particular feature (your suggestion).

[tarcieri]

Per the linked issue:

There are multiple thousand intrinsics for various platforms which users might want to use to speed up their code. It is unrealistic to implement all of these (although a certain subgroup […] seem to be manageable.)

So unless miri is explicitly known to have support, it really it needs to be hard disabled (essentially the opposite of what enabling a target feature with cpufeatures does today), such that the architecture-specific instructions are never emitted, or miri will reject them.

[jrose-signal]

I don't see a practical difference between "hard-disable" and "respect the compiler". If you're running under miri, it's incorrect to provide -C target-feature=blah for something miri doesn't support, whether or not cpufeatures is involved.

[tarcieri]

I suppose that’s true, although at the same time we know a priori the set of target features supported under miri is the empty set.

You could argue relying on target features is futureproofing, but my issue is we don’t yet know what “target features emulated by miri” would actually look like, and I’d prefer not to try to “support” them until we have a clearer picture of that.

Based on that issue it seems like something miri may never support, with emulation always handled at the library level by first detecting if miri is in use.

[jrose-signal]

Does this mean I should change my PR to have cpufeatures say false, or that I should send PRs to the rest of the RustCrypto crates to check cfg(miri)?

[tarcieri]

The former would be my inclination, at least until there is a concrete notion of a miri-supported target feature