@camel-cdr.bsky.social rvv-bench is used here!

Recently I came across this treatise by Stephen Dolan

github.com/ocaml/ocaml/...

256 loads, since it’s an LMUL 8 load with VLEN=256! I’m not sure how it compares to the scalar equivalent, but my guess is that the vlse8.v is loading one element at a time under the hood

The maximum possible vl is 2^16 I think, so that would fit in XLEN=32?

With that said I forgot how confusing the V extension hierarchy can be. After thinking about about EEW=64 on XLEN=32 I think I need to go lie down a bit 😵‍💫

Otherwise EEW=64 is supported as usual, since there’s also this bit at the bottom:

> The V extension requires the scalar processor implements the F and D extensions

Is it this bit here?

> The V extension supports all vector load and store instructions (Section Vector Loads and Stores), except the V extension
does not support EEW=64 for index values when XLEN=32.

I’m interpreting that as index values I.e only indices passed to vluxei64.v and friends

Are you talking about zve32x? That doesn’t include any fp support, but zve32f should mandate f and zve64f should mandate d I think

Even better is being able to measure the numbers yourself without the need for vendor tables. RISC-V support for llvm-exegesis is landing soon IIUC, with RVV not too far behind either.

The RVV Agner Fog is camel-cdr.github.io/rvv-bench-re..., it’s an incredibly useful resource. We use it all the time for LLVM!