This repository was archived by the owner on Dec 22, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Dec 22, 2021. It is now read-only.
Should v8x16.shuffle be i8x16.shuffle? #38
Description
The v8x16.shuffle name correctly avoids interpreting the lanes as integers, but it is the only instruction using this style of vector type naming, so it can be confusing and surprising to the reader (e.g. me). There are also no interpretations of an 8-bit lane other than i8, so avoiding lane interpretation in the name seems unnecessary. I therefore propose changing v8x16.shuffle to i8x16.shuffle based on the principle of least astonishment.
Activity
sunfishcode commentedon Sep 5, 2018
To me the surprising thing is the choice to use a single shuffle that's independent of lane size or element type, because that's different from most other SIMD abstraction layers. But with that design, the name
v8x16.shuffleseems natural. It's not an 'i' integer operation, because this is the way one shuffles floating-point operators too. So it's similar to names likev128.const.tlively commentedon Sep 5, 2018
I wonder if v128.shuffle would make more sense, then. As you mentioned, this instruction is currently the only way to shuffle vectors of any type, and the "v128" prefix strikes me as a good choice for instructions that operate on full vectors without interpreting lane boundaries or contents. I don't feel too strongly about this, though. The "v8x16" name was just surprising to me when I first saw it.
arunetm commentedon Sep 24, 2018
v8x16.shuffle was preserved as its functionality subsumed all other shuffles. It makes sense to preserve the v128.shuffle naming for the reasons pointed out above.