Open DevJPM opened 4 years ago
For the intrinsics we don't actually make any guarantees on what instructions the compiler will generate, so the tests are actually more picky than they should be. In general you shouldn't be using any -C target-cpu
flags when running the tests except for ARM which needs -C target-feature=+neon
.
How would one go about fixing this, i.e. making the assertion accept a v
prefix in specific cases?
You should not pass -C target-cpu=native
when running cargo test
.
I have access to an Intel Ice Lake CPU which has AVX-512 (and VAES / VPCLMULQDQ) support, it was this CPU that produced the below results.
When I follow the updated CONTRIBUTING.MD (#390) with
-C target-cpu=native
I get quite a few codegen tests forcore_arch
to fail. The reason seems to be that LLVM (or the disassembler) for some of these instructions doesn't report back their normal name, e.g.aesenc
but rather their vectorized counter-part, e.g.vaesenc
even though the right instruction was generated. This confuses the tool that checks the disassembly for the instruction and lets the test fail. I think this happens on all CPUs that support AVX-512 (i.e. starting from Skylake-X for Intel).For completeness: I'm running on Arch Linux with rust nightly (
cargo 1.49.0-nightly (79b397d72 2020-10-15)
) and this invocation (on an Ice Lake CPU):RUSTFLAGS="-C target-cpu=native" TARGET=x86_64-unknown-linux-gnu cargo +nightly test --release -p core_arch
Here's a structural example:
And here's the list of tests that fail: