[PATCH] D156249: [RISCV] Implement getOptimalMemOpType for memcpy/memset lowering

[Philip Reames via Phabricator via llvm-commits]

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

This patch implements the getOptimalMemOpType callback which is used by the generic mem* lowering in SelectionDAG to pick the widest type used.  This patch only changes the behavior when vector instructions are available, as the default is reasonable for scalar.

Without this change, we were emitting either XLEN sized stores (for aligned operations) or byte sized stores (for unaligned operations.)  Interestingly, the final codegen was nowhere near as bad as that would seem to imply.  Generic load combining and store merging kicked in, and frequently (but not always) produced pretty reasonable vector code.

The primary effects of this change are:

1. Enable the use of vector operations for memset of non-constant.  Our generic store merging logic doesn't know how to merge a broadcast store, and thus we were seeing the generic (and awful) byte expansion lowering for unaligned memset.
2. Enable the generic misaligned overlap trick where we write to some of the same bytes twice.  The alternative is to either a) use an increasing small sequence of stores for the tail or b) use VL to restrict the vector store.  The later is not implemented at this time, so the former is what previously happened.  Interestingly, I'm not sure that changing VL (as opposed to the overlap trick) is even obviously profitable here.

One thing I intentionally left out of this was lowering for operations with size less than min-VLENB.  I've got some thoughts there, but I'm not sure exactly where we're going to settle yet, and my first attempt seems to require some changes to generic code which seemed worth separating.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D156249

Files:
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/lib/Target/RISCV/RISCVISelLowering.h
  llvm/test/CodeGen/RISCV/rvv/memcpy-inline.ll
  llvm/test/CodeGen/RISCV/rvv/memset-inline.ll
  llvm/test/CodeGen/RISCV/rvv/rvv-out-arguments.ll
  llvm/test/CodeGen/RISCV/rvv/wrong-chain-fixed-load.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D156249.544019.patch
Type: text/x-patch
Size: 48722 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230725/7ba282e1/attachment.bin>