Repository navigation
Rework the safe_wrappers feature / downcasting ability #166
Description
There's a proof-of-concept safe_wrappers feature that's supposed to let you use your own custom architecture-specific SIMD code if you want to, by obtaining an architecture-specific SIMD token from Level using as_neon, as_avx2, etc.
This isn't the ideal abstraction for a couple reasons:
- You need to pass the
Levelall the way down into every SIMD function you use. - The
as_[platform]methods onLevelincur a runtime cost. When a SIMD-using function calls some method on theSimdtoken it's passed, that token's type is statically known, because it's a type parameter.Level, however, is always an enum.
I think #108 starts to move in a different direction, but it creates a lot of autogenerated code, is not fully implemented (WASM is missing), and doesn't actually tie into fearless_simd as implemented. It also seems to have stalled out.
In the meantime, I propose adding as_[platform] methods on the Simd trait itself. The default method implementations would all return None, and individual implementations (Sse4_2, Neon, etc.) could override specific methods to all return Some(self). This means we don't need to pass down the Level, and the new as_[platform] methods would be statically dispatched.
Activity
DJMcNab commentedon Jan 7, 2026
So, #108 can't change anything about WASM, because the SIMD level is always global on WASM.
It is the case that it's not implemented for aarch64 (to be specific, the core abstraction works for all platforms, but the).
Yes, that's correct; I still believe that the abstraction is valuable for consumers of Fearless SIMD, but I'm less certain about my prior comments around using it to implement Fearless SIMD itself; I do suspect that the overhead would be too much. Ideally, of course, rustc would just give us rust-lang/rfcs#3820 (which is implemented in rust-lang/rust#145573), making that need moot.
I've just revisited it as part of writing this comment, and realised that this stalling out is my fault. Hopefully we can get it back into gear now.
I'm in favour of the proposed
as_platformmethods. Those wouldn't be needed in a world with #108 (or at least, the natural extension to it), but that could take a while to actually get moving.Even KISS-er access to intrinsics (linebender#214)
Rip out `core::arch` wrappers (linebender#216)
Shnatsel commentedon Jun 18, 2026
Fulfilled by #214 and #216