Phase 1, week 8retrospective

Fixed versus scalable comparison

Fixed and scalable paths differ in lane utilisation and code shape, not correctness; only -mrvv-vector-bits=zvl bakes in VLEN.


Three differences, three commands

llvm-size bin/matmul_fixed bin/matmul_scalable
llvm-objdump -d bin/matmul_fixed   | grep -c vsetivli
llvm-objdump -d bin/matmul_scalable | grep -c vsetvli

Code size from the text column, AVL handling from the instruction mix, and the timing table at two vlen settings. Until you run them the cells hold <fixed-text>, <scalable-text> and <median>.

The fixed path is not vsetvli-free. It uses vsetivli with the constant 8, which fits the five-bit immediate, or a vsetvli whose AVL is that constant. The difference from the scalable path is not whether the vector configuration is set, it is whether the length is a literal.

Why they differ

Take a fixed eight-lane row, vector<8xf32>. It reaches LLVM as <8 x float>. There are no fixed-length vector registers on RISC-V, so the value is wrapped into a scalable container with insert_subvector and extract_subvector, and the operation runs through a VL node whose AVL is the constant 8. That is legal at every VLEN and it never uses more than eight lanes, so at VLEN=1024 seven eighths of each register does nothing.

The scalable path asks vsetvli for a length and gets min(AVL, VLMAX), so a full iteration fills the register at every VLEN, and the last iteration carries a smaller vl instead of a separate remainder loop. The fixed path needs that remainder loop in the source, which is code size and branches the scalable path does not pay.

-mrvv-vector-bits=zvl lets fixed-length code assume the real VLEN, which changes both builds. The flag spelling is release-bound, so confirm it against the build you pinned. If you use it, say so in the table footnote: the comparison is then VLEN-agnostic fixed against VLEN-specific fixed, and those are different experiments.

Things that break

Comparing fixed at vlen=256 against scalable at vlen=128. The rig moved between the arms, so the difference belongs to QEMU’s configuration rather than to codegen. The other failure is quoting the dec column of llvm-size as code size, which folds data and BSS into a number you then attribute to instructions.

Sources

A version records the documentation the claim was checked against, not a house pin. Confirm flags with --help on the release you installed.

Check yourself

How does a fixed `vector<8xf32>` reach the RVV backend?

At VLEN=1024, what does the fixed-width path do with the extra lanes?

You compare the fixed path at `vlen=256` with the scalable path at `vlen=128`. What have you measured?

0 / 3 correct

← back to the map