[all-commits] [llvm/llvm-project] ff5e53: [RISCV] Add combines to form binop from tail inser...

Philip Reames via All-commits all-commits at lists.llvm.org
Thu Nov 30 07:32:56 PST 2023


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

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVISelLowering.cpp
    M llvm/test/CodeGen/RISCV/rvv/concat-vector-insert-elt.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-buildvec-of-binop.ll

  Log Message:
  -----------
  [RISCV] Add combines to form binop from tail insert idioms (#72675)

This patch contains two related combines:
1) If we have an scalar vector insert into the result of a
concat_vector,
   sink the insert into the operand of the concat.
2) If we have a insert of a scalar binop into a vector binop of the
   same opcode and the RHS of both are constant, perform the insert
   and then the binop.

The common theme to both is pushing inserts closer to the sources of the
computation graph. The goal is to enable forming vector bin ops from
inserts of scalar binops at the end of another vector.

For RISCV specifically, the concat_vector transform will push inserts to
smaller vectors. This will have the effect of reducing lmul for the
vslides, and usually doesn't require an additional vsetvli since
the source vectors are already working in the narrower VL.   I tried
that one as a target independent combine first, and it doesn't appear
profitable on all targets.

This is only one approach to the problem. Another idea would be to
aggressively form build_vectors and subvector inserts from the
individual scalar inserts, and then have a transform which sunk a
subvector_insert down through the concat. The advantage of the alternate
approach is that we expose parallelism in the insert sequence, even if
the source vector isn't a concat_vector. If reviewers are okay with it,
I'd like to start with this approach, and then explore that direction in
a follow up patch.




More information about the All-commits mailing list