QEMU with RVV running

The rig, exactly

Two commands stand between you and every number in this project. Build a static binary that contains vector code, then run it on an emulated CPU with the vector extension switched on:

riscv64-linux-gnu-gcc -march=rv64gcv -mabi=lp64d -static -O2 -o vadd vadd.c
qemu-riscv64 -cpu rv64,v=true,vlen=256,elen=64,vext_spec=v1.0 ./vadd

-static removes the target sysroot from the setup. A dynamically linked binary needs -L /usr/riscv64-linux-gnu so QEMU can find the guest loader, which is one more thing to get wrong before a single measurement exists. vlen=256 is a property of the emulated CPU, not of the binary: it sets the vector register length in bits, so the same executable behaves differently under vlen=128.

Prove the vector unit ran

A binary built with -march=rv64gcv is not evidence that a vector instruction executed. Look at the object code:

riscv64-linux-gnu-objdump -d vadd | grep -c vsetvli

Zero matches means the compiler emitted scalar code, usually because the loop was too short or the pointers could alias. Fix the source, not the flags.

Under this rig llvm.vscale is 4. LLVM defines vscale as VLEN/64, and in <vscale x n x float> the pair of n and the element type encodes LMUL and SEW: with f32 at VLEN=256 the single-register type is <vscale x 2 x float>, which is 8 floats, or 256 bits. That ratio is how you will read every vsetvli in a disassembly later.

Things that break

A trap on Illegal instruction before any output means the emulated CPU has V disabled: QEMU raises SIGILL instead of falling back to scalar code. If QEMU rejects the -cpu string as an unknown property, that release has likely dropped the pre-1.0 encoding, so run qemu-riscv64 -cpu help and pass v=true alone if vext_spec is absent from the list. Many cheap boards implement RVV 0.7.1 rather than 1.0, with different intrinsics and encoding, so this rig stays the reference point rather than the board.