[all-commits] [llvm/llvm-project] 1c9438: [RISCV] Introduce VLOptimizer pass (#108640)

[Michael Maitland via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1c94388f38c61c77d16abd9e164c78790ab23b58
      https://github.com/llvm/llvm-project/commit/1c94388f38c61c77d16abd9e164c78790ab23b58
  Author: Michael Maitland <michaeltmaitland at gmail.com>
  Date:   2024-10-11 (Fri, 11 Oct 2024)

  Changed paths:
    M llvm/lib/Target/RISCV/CMakeLists.txt
    M llvm/lib/Target/RISCV/RISCV.h
    M llvm/lib/Target/RISCV/RISCVTargetMachine.cpp
    A llvm/lib/Target/RISCV/RISCVVLOptimizer.cpp
    A llvm/test/CodeGen/RISCV/rvv/vl-opt-instrs.ll
    M llvm/test/CodeGen/RISCV/rvv/vl-opt-op-info.ll

  Log Message:
  -----------
  [RISCV] Introduce VLOptimizer pass (#108640)

The purpose of this optimization is to make the VL argument, for
instructions that have a VL argument, as small as possible. This is
implemented by visiting each instruction in reverse order and checking
that if it has a VL argument, whether the VL can be reduced.

By putting this pass before VSETVLI insertion, we see three kinds of
changes to generated code:
1. Eliminate VSETVLI instructions
2. Reduce the VL toggle on VSETVLI instructions that also change vtype
3. Reduce the VL set by a VSETVLI instruction

The list of supported instructions is currently whitelisted for safety.
In the future, we could add more instructions to `isSupportedInstr` to
support even more VL optimization.

We originally wrote this pass because vector GEP instructions do not
take a VL, which leads us to emit code that uses VL=VLMAX to implement
GEP in the RISC-V backend. As a result, some of the vector instructions
will write to lanes, specifically between the intended VL and VLMAX,
that will never be read. As an alternative to this pass, we considered
adding a vector predicated GEP instruction, but this would not fit well
into the intrinsic type system since GEP has a variable number of
arguments, each with arbitrary types. The second approach we considered
was to put this pass after VSETVLI insertion, but we found that it was
more difficult to recognize optimization opportunities, especially
across basic block boundaries -- the data flow analysis was also a bit
more expensive and complex.

While this pass solves the GEP problem, we have expanded it to handle
more cases of VL optimization, and there is opportunity for the analysis
to be improved to enable even more optimization. We have a few follow up
patches to post, but figured this would be a good start.

---------

Co-authored-by: Craig Topper <craig.topper at sifive.com>
Co-authored-by: Kito Cheng <kito.cheng at sifive.com>



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications