Repository navigation
Are shuffle's lane indices dynamic? #33
Description
Reading the spec:
Shuffle lanes
v8x16.shuffle(a: v128, b: v128, s: LaneIdx32[16]) -> v128
it appears that the lane indices argument for the shuffle intrinsic is a non-immediate mode argument.
If my memory doesn't fail me:
-
LLVM's
shufflevectorrequires compile-time indices. -
Most architectures do not support shuffling vector lanes of arbitrary width with dynamic indices:
- x86/x86_64 SSSE3's pshufb (and AVX-512 variants) support shuffling bytes with non-immediate mode indices
- ARM 32/64 vtbl/vtbx family of instructions support shuffling bytes with non-immediate mode indices
That is, if the user is shuffling a v8x16, we can use those instructions directly to shuffle with dynamic indices without issues.
If the user attempts to shuffle a v16x8, v32x4, etc. what's the best machine code that we can generate for dynamic indices?
If I remember correctly, generating the appropriate sequence of shuffle bytes instructions requires knowing the lane indices during machine code generation. If these aren't known, the only thing a code generator could do AFAICT is fall back to scalar code, that is, copy the vectors to memory, do a scalar shuffle there e.g. by copying into a third vector, and copy the result of this third vector back to a vector register. This sounds like a huge performance cliff to me.
What am I missing? How can we generate efficient vector shuffles from dynamic lane indices?
Activity
[-]shuffle lanes takes dynamic lane indices[/-][+]Are shuffle's lane indices dynamic? [/+]gnzlbg commentedon Aug 7, 2018
Duh...
What I was missing is that
LaneIdx32is an immediate mode operand.Honestly, I think the spec should be a bit more idiot proof here, by:
LaneIdx32toImmLaneIdx32(for consistency withImmByte)sargument inv128.shuffletosImm,imm, or similarRename LaneIdx{2,4,8,16,32} to ImmLaneIdx{2,4,8,16,32}
gnzlbg commentedon Aug 8, 2018
So it appears that
LaneIdxare not always immediate mode operands (e.g. in theextract_lanesinstructions), which would mean that my original interpretation of the spec is correct, and that the vector shuffles accept dynamic run-time indices.So I am re-opening this for clarification.
gnzlbg commentedon Aug 8, 2018
@billbudge how does V8 implement these?
gnzlbg commentedon Aug 8, 2018
Duh again. So yeah, the lane indices are dynamic, but that's ok because the
shuffleonly operates onv8x16and one can generate efficient code for that on pretty much every architecture.gnzlbg commentedon Aug 8, 2018
So... no... the https://github.com/WebAssembly/simd/blob/master/proposals/simd/BinarySIMD.md document says that these operands are immediate mode arguments...
And that the operands for extract lanes are immediates as well...
I'm leaving this open until someone clarifies and the spec is made idiot proof. To check whether
v8x16shuffle takes immediate arguments or not, I read the definition in the spec, which doesn't mention it and doesn't call the argumentimm, like other places in the spec do. Then I have to jump to the definition of theLaneIdxtypes, which do not start withImm_likeImmBytesdo, and then I have to look at the binary encoding doc which does state that these are immediates. . .I mean, is it me, or is the spec currently unnecessarily ambiguous ?
If instead of all that I would just read
v8x16.shuffle(..., imm: ImmLaneIdx[16])and had a comment next to it saying thatimmis an immediate mode operand, the spec would be crystal clear.penzn commentedon Sep 25, 2018
They are immediate mode arguments, and so are the arguments to hardware shuffle operations (at least on some popular platforms). I don't know why the wording in the spec is the way it is, but you can definitely try submitting a PR to correct it :)
billbudge commentedon Dec 12, 2018
V8's implementation treats the lane index vector as an immediate value. However, there's a strong case to add the dynamic (dynamic shuffle held in a vector register) shuffle. See #24
gnzlbg commentedon Dec 13, 2018
For what it's worth, there has been a PR that closes this issue open for a long time (#34), who should I ping to figure out what's required for it to make progress ?
There has also been a PR open to address that for a long time and that hasn't seen much progress: #30 .
binji commentedon Dec 13, 2018
@aretmr @PeterJensen are the SIMD champions, perhaps they have thoughts about this.
dtig commentedon Dec 14, 2018
I've left comments on #34, and opened issue #58 to handle triage of the older issues/PRs.
Rename LaneIdx{2,4,8,16,32} to ImmLaneIdx{2,4,8,16,32} (#34)
gnzlbg commentedon Mar 2, 2019
IIRC this was fixed by #34 , thank you all!