[PATCH] D103269: [RISCV] Reserve an emergency spill slot for any RVV spills

[Hsiangkai Wang via Phabricator via llvm-commits]

HsiangKai added a comment.

In our downstream implementation, we do not go through SelectBaseAddr for vector load/store to generate ADDI for the base address. In this way, we have no need to reserve one
additional scavenging slot for vector load/store.

Some snippet looks like this.

  // Load
  -  def : Pat<(vti.Vector (riscv_vle_vl BaseAddr:$rs1, VLOpFrag)),
  -            (load_instr BaseAddr:$rs1, GPR:$vl, vti.Log2SEW)>;
  +  def : Pat<(vti.Vector (riscv_vle_vl GPR:$rs1, VLOpFrag)),
  +            (load_instr GPR:$rs1, GPR:$vl, vti.Log2SEW)>;
     // Store
  -  def : Pat<(riscv_vse_vl (vti.Vector vti.RegClass:$rs2), BaseAddr:$rs1,
  +  def : Pat<(riscv_vse_vl (vti.Vector vti.RegClass:$rs2), GPR:$rs1,
                             VLOpFrag),
  -            (store_instr vti.RegClass:$rs2, BaseAddr:$rs1, GPR:$vl, vti.Log2SEW)>;
  +            (store_instr vti.RegClass:$rs2, GPR:$rs1, GPR:$vl, vti.Log2SEW)>;

The drawback is it will generate `addi xa, xa, 0` if the offset is 0.

  -; LMULMAX2-RV32-NEXT:    vsetivli a1, 8, e16,m1,ta,mu
  -; LMULMAX2-RV32-NEXT:    vle16.v v25, (sp)
  +; LMULMAX2-RV32-NEXT:    mv a1, sp
  +; LMULMAX2-RV32-NEXT:    vsetivli a2, 8, e16,m1,ta,mu
  +; LMULMAX2-RV32-NEXT:    vle16.v v25, (a1)

Your implementation is the most precise way to detect the vector load/store frame objects. It scans all the instructions and all the operands in the instruction to detect it.
What is the impact of the compile time if we scan all these instructions in the frame lowering?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103269/new/

https://reviews.llvm.org/D103269