Could shift by 0 on vsll/vsrl/vsra.vi be used to encode shift of 32 instead?

[topperc]

Since shifting by 0 is useless, could this encoding be used to increase the shift amount range to include 32? I believe RV128C does something similar with C.SLLI to encode a shift of 64.

This came up in a conversation about supporting SEW=64 on RV32. @Hsiangkai had a prototype patch for LLVM that used this sequence to put a 64-bit value from two scalar registers into a vector.

vmv.v.x VHi, Hi
vsll.vx VHiShift, VHi, 32. <- This shift amount doesn't fit in vsll.vi so will need a GPR register.
vadd.vx VOp, VHiShift, Lo
vop.vv vd, vs2, VOp

[nick-knight]

That's a cool idea. In fact, there's a whole list of arithmetic operations that are no-ops with zero immediate that could benefit from a similar trick.

[kasanovic]

There should a later vector extension that covers more bit manipulation operations including shifts/rotates, so don't want to complicate base instructions as these operations will get subsumed.

The example is somewhat niche, and putting immediate in scalar register is not a big overhead.

The NOPs will be repurposed as HINTs.

[David-Horner]

@kasanovic The NOPs will be repurposed as HINTs.

As a probable strategy, I agree. However, we may find a preferred purpose for them .... just sayin'.

IMHO it is correct that we keep them open for future use.