Support for `_mm_clflushopt`

[thomcc]

We don't have a core::arch::{x86_64,x86} intrinsic for _mm_clflushopt. I think this would need a new clflushopt target feature.

I don't mind implementing this.

[Amanieu]

LLVM has a clflushopt, so it's fine to do the same here.

[jlpetz]

Hi All,

I'm trying to re-write an old memory testing app called TM5 (https://testmem.tz.ru/testmem5.htm) in Rust, while adding a bunch of new features. AI assisted of course as I'm not a great programmer. Sorry if that makes you cringe.

I've had some fun trying to get SIMD non-temporal writes working, as it seems core::intrinsics::nontemporal_store just does compiler hints to LLVM, but these seem to get stripped by Rust/LLVM optimiser cycles. So for that I've admitted defeat and just went with std::arch intrinsics (_mm512_stream_si512), which emits inlines ASM with #APP/#NO_APP that is Opaque to LLVM and means manual unrolling is needed :( But given I have seen a good amount of debate on this topic and how to address it, I'll park it for another ask. It seems most people prefer targetting this way anyway to ensure full control of low level code. Though I thought Rust would have tried abstracting it at a higher level.

Anyway, like the author of this post I would like support for the _mm_clflushopt intrinsic to core::arch::x86_64, which is hopefully more straight forward then non-temporal. It would complete Rust’s coverage of the x86 cache‑flush and persistence‑related instructions and remove unneeded assembly. The implementation as I understand it would be a thin wrapper around LLVM’s existing intrinsic llvm.x86.clflushopt, consistent with how _mm_clflush and _mm_clwb are exposed.

Motivation

Rust currently exposes:

• _mm_clflush (stable)
• _mm_clwb (nightly)
• _mm_sfence (stable)

…but does not expose _mm_clflushopt, even though:

• LLVM provides the intrinsic
• The instruction is widely supported (Skylake and newer)
• It is part of the same family of cache‑management instructions

I'm after it, as in my micro benchmark CLFLUSHOPT was ~15× faster than the only currently-exposed flush (_mm_clflush/SSE2). So this will definetly be helpful in my memory testing app.

  ┌─────────────────────────────┬─────────┬────────┬──────────────────────┐
  │           Variant           │  MiB/s  │ cyc/CL │    Unstable gates    │
  ├─────────────────────────────┼─────────┼────────┼──────────────────────┤
  │ clflush (SSE2)              │  ~1,700 │    ~97 │ none                 │
  ├─────────────────────────────┼─────────┼────────┼──────────────────────┤
  │ clflushopt (asm)            │ ~25,200 │   ~6.5 │ none                 │
  ├─────────────────────────────┼─────────┼────────┼──────────────────────┤
  │ clflushopt (llvm intrinsic) │ ~25,200 │   ~6.5 │ 2 (both discouraged) │
  └─────────────────────────────┴─────────┴────────┴──────────────────────┘