4 ms·

If what camel-cdr in another comment here said is correct, the single-cycle vrgather wouldn't apply to anything not written specifically for X280 as I doubt any

by dzaima 2y ago

If what camel-cdr in another comment here said is correct, the single-cycle vrgather wouldn't apply to anything not written specifically for X280 as I doubt anything anywhere is attempting to use LMUL=1/2 for 128-bit or 256-bit vrgather. But, sure, X280 might not be intended for general-purpose usage. Still pretty sure that won't stop people from trying. And it's far from impossible, and, to some extent even reasonable, for future hardware to be intended for general-purpose usage while still disadvantaging fixed-width. And, for a good number of fixed-width SIMD usages, the alternative might not necessarily be "do everything exactly as with SIMD but in scalar registers with one instruction per would-be-SIMD-element"; namely, SWAR could be utilized, some shifts/rotates/bswap/multiplies used in place of shuffles, entirely different algorithms used, and you wouldn't need to duplicate computation for something like a cumulative sum/xor that on SIMD would've been implemented as log2(n) slides. I've had a good number of cases where some fixed-width x86 SIMD thing is only marginally faster than the scalar baseline. I'm not saying this is some utter massive disaster that'll kill RVV; but vrgather definitely, as-is, is pretty inadequate for many things that it can actually do purely due to forcibly having both operands have the same LMUL and having only that as the cap on the table size; and it is unquestionably possible (though not guaranteed, and maybe even unlikely) that in the future software will be expected to handle funky-tradeoff hardware, which'd suck for software developers.

brucehoult 2y ago
I will agree with you on one thing. Having `vrgather` use the same `LMUL` for both operands is not ideal. It's natural, of course, for permutations, where the actual data is in the lookup table and the indexes are the permutation, but not for other uses where the indexes are the data and the table is a table. Having the table ignore `vl` is also ugly. The proper solution would, I think, be to have duplicate `vtype` and `vl` CSRs that are set up by a different `vsetvl2` instruction. It would be seldom-enough used to dispense with the opcode-expensive immediate form and only take the type from a register, making it a cheap I-type instruction. This would also solve the problem of table and indexes having different element sizes that prompted the late creation of the `vrgather16` instruction and imposition of the artificial 65536 bit limit on `VLEN` in RVV 1.0 and foreshadowing of a potential future `vrgather32`.
- dzaima 2y ago
  That's an interesting solution. Would also not be unreasonable for like indexed loads/stores, though there fully getting rid of the built-into-instruction element type would have its problems. While vrgatherei32 is certainly definable, it not existing does have the benefit of not burdening small impls with yet more connections for indices. Also, vrgatherei64, spooky.

by dzaima 2y ago

brucehoult 2y ago

I will agree with you on one thing. Having `vrgather` use the same `LMUL` for both operands is not ideal. It's natural, of course, for permutations, where the actual data is in the lookup table and the indexes are the permutation, but not for other uses where the indexes are the data and the table is a table. Having the table ignore `vl` is also ugly. The proper solution would, I think, be to have duplicate `vtype` and `vl` CSRs that are set up by a different `vsetvl2` instruction. It would be seldom-enough used to dispense with the opcode-expensive immediate form and only take the type from a register, making it a cheap I-type instruction. This would also solve the problem of table and indexes having different element sizes that prompted the late creation of the `vrgather16` instruction and imposition of the artificial 65536 bit limit on `VLEN` in RVV 1.0 and foreshadowing of a potential future `vrgather32`.

dzaima 2y ago
That's an interesting solution. Would also not be unreasonable for like indexed loads/stores, though there fully getting rid of the built-into-instruction element type would have its problems. While vrgatherei32 is certainly definable, it not existing does have the benefit of not burdening small impls with yet more connections for indices. Also, vrgatherei64, spooky.