[PATCH] D155618: [RISCV] Reduce alignment of vector constant pool entries

[Philip Reames via Phabricator via llvm-commits]

reames created this revision.
reames added reviewers: craig.topper, asb, frasercrmck, kito-cheng, luke.
Herald added subscribers: jobnoorman, VincentWu, vkmr, luismarques, apazos, sameer.abuasal, pengfei, 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: wangpc, eopXD, MaskRay.
Herald added a project: LLVM.

For RVV, we are very reliant on constant pools for fixed length constants.  The default lowering for constant pool aligns the entry to the ABI alignment.  For a vector, this is usually the size of the type in question.  As this isn't actually exposed in the ABI (right?!), the resulting alignment creates a bunch of extra padding with no value.

This change reduces the alignment used to be the vector element alignment.  This closely matches the reasoning in the allowsMisalignedMemoryAccesses routine (and we assert they're in sync.)  Note that our instruction choice doesn't change; only the alignment of the constant pool entry.

Performance effects here may be a bit complicated, but I think (hope?) it should be generally positive.  Potential downsides include:

- Placing data immediately after end of the previous function.  This may confuse instruction decode which is fetching in chunks, and tries to decode the data as instructions.
- Changing the working set of the following function.  By removing alignment, we may either decrease or increase the size of this set.  Note that we actually have two working sets to consider - d-cache and i-cache.  Each can change independently.

Note that the downsides above already apply to non-vector data (since they are naturally less aligned).  If we have a processor which has problems with the above items, we should probably be trying to mitigate the general issues as opposed to getting lucky due to vector constant pools.  :)

Note: I'd originally tried to do something here which was more target independent, but I found that a) reducing alignment caused massive test diffs, and b) exposed what appeared to be a number of missing folds on x86.  Thus the target specific hook approach taken here.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D155618

Files:
  llvm/include/llvm/CodeGen/TargetLowering.h
  llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/lib/Target/RISCV/RISCVISelLowering.h
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-constant-pool-alignment.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D155618.541586.patch
Type: text/x-patch
Size: 5221 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230718/e4e6a96a/attachment.bin>