RISC-V intrinsics in Miri

[nazar-pc]

Miri doesn't seem to support any of the numerous RISC-V intrinsics yet.

I have implemented a bunch of them as part of my RISC-V interpreter under 0BSC license and wondering what would it take to maybe upstream them into Miri itself?

Specifically, I have implemented the following RISC-V extensions (RV32 and RV64 flavors of each where applicable), and any intrinsic present there is implemented as the result:

• M
• B
• Zba
• Zbb
• Zbc
• Zbkb
• Zbkc
• Zbkx
• Zbs
• Zca
• Zcb
• Zcmp
• Zkn
• Zknd
• Zkne
• Zknh
• Zicond
• Zicsr
• Zvbb
• Zvbc
• Zve64x
• Zvkb

Implementations have basic unit tests, including under Miri, in CI, as well as validation against RISC-V Architectural Certification Tests as part of comprehensive integration/end-to-end testing.

Intrinsics are hardware-accelerated where possible, for example, RV64 Zknd/Zkne are implemented using platform-specific AES intrinics on aarch64 and x86-64. As more extensions are implemented, more intrinsics may be covered and contributed back to Miri.

I can extract intrinsics into a separate small crate if that is preferred/desirable or the code could be just copied instead (I have no issues with it being relicensed to whatever).

[RalfJung]

Thanks for offering your intrinsic implementations!

Given the sheer number of intrinsics across even just the main architectures (x86-64, aarch64, riscv), we do not aim to comprehensively support all intrinsics in Miri. We support a lot of x86 since it is the dominant architecture and having one architecture well-supported means we can cover most of the higher-level codepaths at least once (i.e., there is one target you can use to actually test your code, and "just" the target-specific bits for other targets are not covered). Even there, we're not going to cover all of AVX512, it's way too big.

For AVX512, aarch64, and riscv, my policy so far has been that we'll accept PRs for intrinsics where you can demonstrate a benefit to the ecosystem. For instance, we landed the aarch64 intrinsics needed to run zlib-rs, a foundational crate that also uses Miri in its CI. Anything needed to get std::simd to work is also fair game (though ideally that is entirely done by using the target-independent intrinsics). But it's non-trivial work to review these PRs so I'm not going to do that just for the fun of it.

The implementations we do have are all optimized for maximum readability and "obvious" correctness. In particular we do not want to have cfg in Miri itself unless it's absolutely needed. So, we'd be looking for target-independent implementations that use basic Rust operations. Miri is already so slow that I don't think it is worth spending effort on reviewing and maintaining implementations based on host intrinsics. The bar for adding a dependency on an external crate is obviously pretty high as this would get imported into the rustc workspace.

[RalfJung]

Oh and a particular difficulty with RISC-V is proper native testing. For x86 and aarch64 we have CI runners that execute the intrinsic tests as native binaries, to ensure that the baseline we use for Miri is actually correct. We can't easily run CI on RISC-V (AFAIK) so that's going to be harder to get CI coverage for. We don't necessarily need to run the tests natively from the start (we support some CRC intrinsics on loongarch and can't run those tests natively either), but if we have more than a handful of these intrinsics I'd strongly prefer having a way to test them. If I can't even verify that the test is correct (or add and check new testcases myself), reviewing these PRs becomes a lot harder and more exhausting.

[nazar-pc]

It should be possible to test with QEMU, but it'll certainly make CI harder to maintain.

Given the context of the implementation that I already have, it is already being tested against certification tests as "the source of truth", so unless certification tests themselves have bugs, the implementation is correct (assuming you just pull it from external tested crate).

---

I think given lack of urgency and initial response, I'll keep this issue open without opening PRs or now. If anything changes or someone needs support for such intrinsics, I should be able to contribute them.

P.S. There is a benefit for hardware-accelerated intrinsics, at least in some cases. For example, software implementation of AES will likely be ~50x slower than AES-NI (from my past experience), which does seem substantial enough.

[RalfJung]

It's unlikely we'll be able to directly use an external implementation -- intrinsics have to be integrated with Miri's data model and the way it manages the interpreter state. So we'll definitely want our own tests and want to be sure they are correct. Have a look at what this looks like for aarch64 if you are curious.

• implementation
• tests

For example, software implementation of AES will likely be ~50x slower than AES-NI (from my past experience), which does seem substantial enough.

Miri is >1000x slower than native execution so 50x is still faster than most of Miri, and not worth any effort to further optimize. Unless your program consists entirely of AES calls you'd probably not even notice the difference.

[RalfJung]

It should be possible to test with QEMU, but it'll certainly make CI harder to maintain.

FWIW we already have fully set up CI jobs that use user-mode QEMU and Ubuntu multilib to run everything on RISCV. However

• the ubuntu packaging mirrors for RISCV are extremely unreliable, so we had to disable the job
• this is so slow that we're only checking whether Miri can build, not actually building Miri or run it

The 2nd point arises because Miri cannot be cross-compiled, so if we want to test whether Miri builds on a riscv host we have to use a riscv host toolchain. If it's just about running "native" tests we wouldn't need to build all of Miri, though it'd be non-trivial to split that out of our test suite I think. And the first point seems like a deeper problem, we can't rely on Ubuntu multilib to get a riscv qemu, we'd have to do something else.