RVV optimization

The source (MLIR vector ops) does not tell what runs: LLVM decides register allocation, how extracts and broadcasts lower, and the schedule. Check the generated code, not only the source.

Workflow

1. Estimate the kernel's floor (bytes / bandwidth, or critical-path instructions x latency, using the target's measured costs in the hardware-targets skill).
2. Microbenchmark the kernel alone (see performance-optimization methodology) and compare.
3. If it is far above the floor, disassemble the hot function and take the instruction histogram (references/codegen-pitfalls.md, "Reading the code"). Look for spills, permutes, slides, scalar moves and redundant vsetvli.
4. Change the structure of the source (loop instead of unroll, fewer live vectors, a different data path for a scalar) and confirm the histogram changed before timing.

Rules of thumb

• Vector length: fix the VLEN when the target is known (+zvl<N>b, -riscv-v-vector-bits-max=<N>; Buddy's BUDDY_RISCV_VLEN). Kernels stay correct for any VLEN.
• 32 vector registers: at LMUL 4 only 8 groups. Count the vectors live across a loop iteration (accumulators, loop-invariant operands, loaded rows) before unrolling; past 8 groups LLVM spills whole groups.
• Unrolling helps an in-order core only while everything stays in registers; a small loop with scalar bookkeeping is often faster.
• Reductions (vfredusum, vfredmax) are long-latency; give the core independent work between them.
• Do not broadcast a vector element with a permute: extract to a scalar (cheap) and use the .vf / .vx form, or read it from memory.
• Prefer fewer, larger loads when load cost is per instruction.
• For in-order cores, schedule with the core's model (-mcpu=...) and try -misched-prera-direction=topdown.

references/codegen-pitfalls.md has the patterns observed in Buddy's kernels and their fixes. Target costs: hardware-targets (e.g. spacemit-k3-instruction-costs.md).