LLVM plans dynamic vector shuffle intrinsic
An RFC for runtime-mask shuffles draws support from Rust, C++26, and SVE and RISC-V backends after years of workarounds.
LLVM is moving toward a dedicated intrinsic for shuffling vector lanes under a runtime mask, after an RFC gathered clear demand from language frontends and multiple architecture backends.
Today’s shufflevector instruction accepts only constant masks. That forces vectorizers and frontends into brittle patterns or target-specific passes when the permutation is data-dependent. Hardware already exposes the operation: Arm SVE and Neon TBL/TBX, RISC-V vrgather, and x86 VPERMV-family instructions all take dynamic indices. Without a first-class IR representation, cost modeling in LoopVectorize and VectorCombine stays inaccurate and lowering remains fragmented.
Nikic judged the use cases sufficient to proceed, preferring a new @llvm.vector.shuffle intrinsic over extending shufflevector. The emerging design keeps a single source vector and forbids length-changing results, so input and output types match. Two-source or multi-register table lookups would be expressed by an explicit concat followed by the shuffle and an extract, or recognized later by target combines. Keeping the operation length-preserving simplifies legalization and costing; scalable vector.reverse and vector.splice would stay as separate intrinsics because they lower to single dedicated instructions on SVE and RVV.
Rust developers have asked for the capability for some time; C++26’s simd.permute.dynamic clause makes the same request from the standards side. On the Arm side, the SVE loop-vectorizer team has already prototyped a similar intrinsic and currently maintains a temporary SVEShuffleOpts pass whose own comments call for exactly this generic form. RISC-V and AVX-512 contributors likewise see a cleaner path to their gather-style permutes.
Open questions remain around mask-element legalization for scalable vectors when vscale ranges are unknown, and whether a variadic form that directly accepts two or four source registers would be worth the extra complexity. The RFC author is revising the proposal to the single-source, fixed-length shape that has attracted the broadest agreement.