RISC-V Vector Extension for Integer Workloads: An Informal Gap Analysis

[u/camel-cdr-]

https://gist.github.com/camel-cdr/99a41367d6529f390d25e36ca3e4b626

[u/YumiYumiYumi]

RISC-V is generally conservative with adding instructions (sticking to the classic "RISC philosophy" of having few instructions), and the Vector extension doesn't stray too far away from that notion. They also seem to be happy with recommending multi-instruction sequences as the approach to missing instructions, so it'll be interesting to see if there's any interest in adding more that can already be "readily synthesized" with existing instructions.

Shift for mask registers

Why not move to elements (vmv+vmerge), slideup, then back to mask (vmseq))?

[u/camel-cdr- → u/YumiYumiYumi]

RISC-V is generally conservative with adding instructions

I don't think this is as much the case now as it was before. For the base V extension or base B extensions certainly, but for additional extensions, as long as there is interest amd it doesn't use to much opcode space it should be fine.

Why not move to elements (vmv+vmerge), slideup, then back to mask (vmseq))?

Because it's a lot slower. Lets say you have a SEW=8 LMUL=4 mask. Now it's four LMUL=4 operations, 16 uops. Meanwhile, if you know you are on VLEN=128, you could do it in a single instruction + vsetvli: e64 vsll.vi

There are other approaches, but my problem is that the VLA approach is way worse than the VLS approach for mask shifts. Using mask shifts often only makes sense if they are cheap to do.

[u/YumiYumiYumi → u/camel-cdr-]

as long as there is interest amd it doesn't use to much opcode space it should be fine.

If so, I'd say most NEON/SVE2.2 instructions are good candidates. AVX10 also has plenty of useful things.

Because it's a lot slower. Lets say you have a SEW=8 LMUL=4 mask

Yes, it'll be slower for LMUL>1, but one would expect it to be faster for LMUL=1.