[PATCH] D132680: [RISCV] Disable SLP vectorization by default due to unresolved profitability issues

Philip Reames via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 25 10:48:31 PDT 2022


reames created this revision.
reames added reviewers: craig.topper, kito-cheng, asb, ABataev.
Herald added subscribers: vporpo, sunshaoce, VincentWu, luke957, StephenFan, vkmr, frasercrmck, evandro, luismarques, apazos, sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, shiva0217, niosHD, sabuasal, bollu, simoncook, johnrusso, rbar, hiraditya, arichardson, mcrosier.
Herald added a project: All.
reames requested review of this revision.
Herald added subscribers: pcwang-thead, eopXD, MaskRay.
Herald added a project: LLVM.

This change implements a TTI query with the goal of disabling slp vectorization on RISCV.  The current default configuration disables SLP already, but its current tied to the ability to lower fixed length vectors.  Over in D131508 <https://reviews.llvm.org/D131508>, I want to enable fixed length vectors for purposes of LoopVectorizer, but preliminary analysis has revealed a couple of SLP specific issues we need to resolve before enabling it by default.  This change exists to allow us to enable LV without SLP.

The major issues for SLP/RISCV I currently know of are:

- We have a cost modeling problem for vector constants.  SLP mostly ignores the cost of materializing constants, and on most targets that works out mostly okay.  RISCV has unusually expensive constant materialization for large constants, so we end up with common patterns (e.g. initializing adjacent unsigned fields with constants) being unprofitably vectorized.  Work on this started under D126885 <https://reviews.llvm.org/D126885>, and there is ongoing discussion on follow ups there.
- We will vectorize sub-word parallel operations and don't have robust lowering support to re-scalarize.  Consider a pair of i32 stores which could be vectorized as <2 x i32> or could be done as a single i64 store.  The later is likely more profitable, but not what we currently generate.  I have not fully dug into why yet.

Note that both of these issues could exist for LV in theory, but are significantly less likely.  LV is strongly biased towards constant splats and longer vectors.  Splats are significantly cheaper to lower (as a class), and longer vectors allows fixed cost errors to be amortized across more elements.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D132680

Files:
  llvm/lib/Target/RISCV/RISCVTargetTransformInfo.cpp
  llvm/lib/Target/RISCV/RISCVTargetTransformInfo.h
  llvm/test/Transforms/SLPVectorizer/RISCV/load-store.ll
  llvm/test/Transforms/SLPVectorizer/RISCV/rvv-min-vector-size.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D132680.455643.patch
Type: text/x-patch
Size: 5953 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220825/214a5993/attachment.bin>


More information about the llvm-commits mailing list