[experiment - feedback needed] Run stdarch tests with Miri

[eduardosm]

I ended with this in an attempt of avoiding duplicating stdarch tests in miri/tests/pass/x86-intrinsics-*.

To run it:

./miri build
MIRI_TEST_TARGET=x86_64-unknown-linux-gnu ./test-stdarch/run-tests.sh

Do we actually want to include something like this? Advantages are:

• We can avoid duplicating tests in stdarch and miri.
• Better coverage (already helped me find a SSE2 intrinsic I forgot to implement)
• Also tests functions that do not require LLVM intrinsics

The main downside is execution time. With only SSE and SSE2, it takes about 3 minutes to complete locally, although most of the time it looks like its doing nothing. Looking at the summary (303 ran, 4274 filtered), my first guess is that it spends a lot of time filtering/skipping/sorting/whatever the test harness does.

test result: ok. 303 passed; 0 failed; 0 ignored; 0 measured; 4274 filtered out

Additionally, it does not integrate very well with other tests. It uses a script that clones the stdarch repository and runs the tests with cargo.

[saethlin]

Looking at the summary (303 ran, 4274 filtered), my first guess is that it spends a lot of time filtering/skipping/sorting/whatever the test harness does.

If I recall correctly, that number of tests used to take more like 15 minutes until I wrote some optimizations for libtest. You can profile the interpreter's execution if you want, with -Zmiri-measureme, which is documented in the README. If you find some easy improvements libs would probably accept them, but 3 minutes is not all that concerning to me. It's a fair price for a lot of test coverage.

[RalfJung]

This sounds more like a case for https://github.com/rust-lang/miri-test-libstd/ than for this repo?

I don't think we want to treat stdarch test different than other std tests. There we duplicate the "most important" tests into Miri to ensure coverage of all code paths in Miri, and then we have miri-test-libstd (runs every morning on the latest nightly) to ensure that we cover the parts of the standard library that we expect to cover.