[all-commits] [llvm/llvm-project] 275eed: [RISCV] Split long build_vector sequences to reduc...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 275eeda32f4f32d2385043f8d1d8af3d4f65bb2c
      https://github.com/llvm/llvm-project/commit/275eeda32f4f32d2385043f8d1d8af3d4f65bb2c
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2024-02-14 (Wed, 14 Feb 2024)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVISelLowering.cpp
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-buildvec.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp2i-sat.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-int-buildvec.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-mask-buildvec.ll

  Log Message:
  -----------
  [RISCV] Split long build_vector sequences to reduce critical path (#81312)

If we have a long chain of vslide1down instructions to build e.g. a <16
x i8> from scalar, we end up with a critical path going through the
entire chain. We can instead build two halves, and then combine them
with a vselect. This costs one additional temporary register, but
reduces the critical path by roughly half.

To avoid needing to change VL, we fill each half with undefs for the
elements which will come from the other half. The vselect will at worst
become a vmerge, but is often folded back into the final instruction of
the sequence building the lower half.

A couple notes on the heuristic here:
* This is restricted to LMUL1 to avoid quadratic costing reasoning.
* This only splits once. In future work, we can explore recursive
splitting here, but I'm a bit worried about register pressure and thus
decided to be conservative. It also happens to be "enough" at the
default zvl of 128.
* "8" is picked somewhat arbitrarily as being "long". In practice, our
build_vector codegen for 2 defined elements in a VL=4 vector appears to
need some work. 4 defined elements in a VL=8 vector seems to generally
produce reasonable results.
* Halves may not be an optimal split point. I went down the rabit hole
of trying to find the optimal one, and decided it wasn't worth the
effort to start with.

---------

Co-authored-by: Luke Lau <luke_lau at icloud.com>