[PATCH] D155218: [InstCombine] Optimize addition/subtraction operations of splats of vscale multiplied by a constant

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 9 11:33:25 PDT 2023

nikic added a comment.

In D155218#4573684 <https://reviews.llvm.org/D155218#4573684>, @paulwalker-arm wrote:

> The rational for making these `vscale` specific transformations is that `vscale` is effectively a constant with targets that support scalable vectors typically having instructions where `vscale` is implied.  This is the same reason why there are no multi-use checks.  Whilst the changes to LoopVectorize output look like regressions the extra IR is loop invariant that will be hoisted and generally leads to better generated code.  This is especially true for cases where vector loops are interleaved.

Is this something that we expect to hold true for all architectures with scalable vectors? I tried to look at sve and rvv codegen here: https://llvm.godbolt.org/z/9xdWrbPKv I can see how the sve case is always beneficial, even for multi-use cases, but the rvv case looks like it would only be an improvement for the one-use case.

  rG LLVM Github Monorepo



More information about the llvm-commits mailing list