SIMD instructions are not supported

constant evaluation error: tried to call a function with ABI RustIntrinsic using caller ABI PlatformIntrinsic
   --> …/nightly-2019-03-15-x86_64-apple-darwin/lib/rustlib/src/rust/src/libcore/../stdsimd/crates/core_arch/src/x86/sse2.rs:819:27
    |
819 |     transmute::<i8x16, _>(simd_eq(a.as_i8x16(), b.as_i8x16()))
    |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ tried to call a function with ABI RustIntrinsic using caller ABI PlatformIntrinsic
    |
    = note: inside call to `std::arch::x86_64::_mm_cmpeq_epi8` at …/memchr/src/x86/sse2.rs:189:34
    = note: inside call to `memchr::x86::sse2::forward_search1` at …/memchr/src/x86/sse2.rs:118:22
    = note: inside call to `memchr::x86::sse2::memchr`

[RalfJung]

Miri currently does not support SIMD instructions at all. Let's use this issue to track that (I don't think we have one already).

[RalfJung]

@flagello a piece of example code would help. Calling memchr should not usually invoke SIMD on Miri, I don't think?

If the machine supports them why not? Consider it‘s rust-memchr rather than libc‘s, and it prefers its own SIMD variants where possible.

[oli-obk]

Related: rust-lang/const-eval#7

[RalfJung]

the machine

Miri interprets your program, it doesn't run it directly on the hardware. The capabilities of the host machine do not matter.

why not?

Because nobody went through the effort of implementing several hundred SIMD intrinsics yet. It's not that we don't want SIMD support, we do, but it's a lot of work.

the machine

Miri interprets your program, it doesn't run it directly on the hardware. The capabilities of the host machine do not matter.

why not?

Because nobody went through the effort of implementing several hundred SIMD intrinsics yet. It's not that we don't want SIMD support, we do, but it's a lot of work.

Sorry, I wasn‘t clear enough—with “why not” I meant “why shouldn‘t memchr invoke SIMD on Miri when, e.g., target_arch is x86_64.” In fact, thank you for your work on Miri!

[RalfJung]

with “why not” I meant “why shouldn‘t memchr invoke SIMD on Miri when, e.g., target_arch is x86_64.”

Ah. That's a good question indeed. :)

Code doing opportunistic SIMD usually relies on align_to. When running in Miri, this method always returns an empty middle slice. That's why the memchr in libstd works fine in Miri.

libcore‘s memchr (i.e., core::slice::memchr::memchr behind #![feature(slice_internals)], for anyone else reading) does not rely on explicit SIMD at all as it‘s Andrew‘s “fallback” (memchr::memchr::fallback) implementation rather than the SSE + AVX ones (which are those that lead to the error when the requirements are satisfied).

A quick workaround is of course,

#[cfg(not(miri))]
memchr(needle, haystack)

#[cfg(miri)]
haystack.iter().position(|&b| b == needle)

[RalfJung]

A little update on this: the issue of supporting SIMD in MIR-based Rust verification tools came up at the Rust Verification Workshop at ETAPS, and there is a lot of interest in finding a shared solution. One avenue we are considering is to have a pure Rust implementation of those intrinsics; tools consuming MIR or LLVM IR should be able to compile that implementation to the required IR and replace intrinsic calls with that IR.

[RalfJung]

Miri now supports the intrinsics needed for potable_simd, which I think closes this issue.