[all-commits] [llvm/llvm-project] e39add: [RISCV] Transform build_vector((binop X_i, C_i)..)...

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e39add89cd25eb689f1dc862b84fae79cd0b2c61
      https://github.com/llvm/llvm-project/commit/e39add89cd25eb689f1dc862b84fae79cd0b2c61
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2023-09-26 (Tue, 26 Sep 2023)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVISelLowering.cpp
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-buildvec-of-binop.ll
    M llvm/test/CodeGen/RISCV/rvv/fixed-vectors-vselect.ll
    M llvm/test/CodeGen/RISCV/srem-seteq-illegal-types.ll
    M llvm/test/CodeGen/RISCV/urem-seteq-illegal-types.ll

  Log Message:
  -----------
  [RISCV] Transform build_vector((binop X_i, C_i)..) to binop (build_vector, build_vector) (#67358)

If we have a build_vector of identical binops, we'd prefer to have a
single vector binop in most cases. We do need to make sure that the two
build_vectors aren't more difficult to materialize than the original
build_vector. To start with, let's restrict ourselves to the case where
one build_vector is a fully constant vector.

Note that we don't need to worry about speculation safety here. We are
not speculating any of the lanes, and thus none of the typical - e.g.
div-by-zero - concerns apply.

I'll highlight that the constant build_vector heuristic is just one we
could chose here. We just need some way to be reasonable sure the cost
of the two build_vectors isn't going to completely outweigh the savings
from the binop formation. I'm open to alternate heuristics here - both
more restrictive and more permissive.

As noted in comments, we can extend this in a number of ways. I decided
to start small as a) that helps keep things understandable in review and
b) it covers my actual motivating case.