[all-commits] [llvm/llvm-project] 144b2f: [RISCV] Start vslide1down sequence with a dependen...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 144b2f579ef06e663cf233431d291a913b895074
      https://github.com/llvm/llvm-project/commit/144b2f579ef06e663cf233431d291a913b895074
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2023-11-17 (Fri, 17 Nov 2023)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVISelLowering.cpp
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-bitcast.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-buildvec-of-binop.ll
    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-i2fp.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-insert.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-llrint.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-load.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-lrint.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-mask-buildvec.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-masked-gather.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-masked-scatter.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-vselect.ll
    M llvm/test/CodeGen/RISCV/rvv/fold-vector-cmp.ll
    M llvm/test/CodeGen/RISCV/srem-seteq-illegal-types.ll
    M llvm/test/CodeGen/RISCV/urem-seteq-illegal-types.ll

  Log Message:
  -----------
  [RISCV] Start vslide1down sequence with a dependency breaking splat (#72691)

If we are using entirely vslide1downs to initialize an otherwise undef
vector, we end up with an implicit_def as the source of the first
vslide1down. This register has to be allocated, and creates false
dependencies with surrounding code.

Instead, start our sequence with a vmv.v.x in the hopes of creating a
dependency breaking idiom. Unfortunately, it's not clear this will
actually work as due to the VL=0 special case for T.A. the hardware has
to work pretty hard to recognize that the vmv.v.x actually has no source
dependence. I don't think we can reasonable expect all hardware to have
optimized this case, but I also don't see any downside in prefering it.