[all-commits] [llvm/llvm-project] 7639a3: [RISCV][InsertVSETVLI] Support constant VLs larger...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7639a39dd25e5035f594430f5bf1bf8e39722aa8
      https://github.com/llvm/llvm-project/commit/7639a39dd25e5035f594430f5bf1bf8e39722aa8
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2023-05-24 (Wed, 24 May 2023)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-interleave.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-int-interleave.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-interleaved-access.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-masked-gather.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-vand-vp.ll
    M llvm/test/CodeGen/RISCV/rvv/shuffle-reverse.ll

  Log Message:
  -----------
  [RISCV][InsertVSETVLI] Support constant VLs larger than immediate encoding

The immediate field on the vsetivli is fairly limited. For larger vectors, we end up having to materialize a constant in a register. We hadn't plumbed the infrastructure to treat such materialized constants as constants for purpose of vsetvli elimination.

I only bothered to handle LI. We could extend this to LUI sequences, but well, 2048 elements is probably enough for all practical fixed length vector codegen. :)

The test delta does point out a related problem. At LMUL8, we see increased register allocation pressure, and we should probably either a) address register allocation remat, or b) be less aggressive about eliminating vsetvlis at high lmul. Note that high LMUL code is not generated much by default.

Differential Revision: https://reviews.llvm.org/D151212