That is exactly my design (or, rather, a design I remember reading in the #riscv IRC room), taking the "could also have only one DLEN-sized table chunk input at

That is exactly my design (or, rather, a design I remember reading in the #riscv IRC room), taking the "could also have only one DLEN-sized table chunk input at the obvious cost" path; i.e. to extend your specification to my double-DLEN-chunk method, you'd have it find two different indices that each select a separate register, and blend those shuffled together all in one uop. https://github.com/llvm/llvm-project/issues/79196 https://github.com/llvm/llvm-project/issues/79196 also mentions this in "we want the elements to come from as few DLENs of the source vector as possible"; and down the comments there is me having had too much fun writing code to fill in "I don't care" index elements such that they don't add any more required chunks, in a completely-DLEN-agnostic way. I don't think this is necessarily that bad for ooo; it's really "just" variable latency, which would already exist to an extent on cores which dynamically scale based on VL (though, granted, not all would be such, and the exact latency would be found much later down the pipeline even then).