[PATCH] D138751: [MemCpyOpt] Expand two memcpy's with clobber inbetween (PR59116)

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri created this revision.
lebedev.ri added reviewers: nikic, fhahn, asbirlea, reames.
lebedev.ri added a project: LLVM.
Herald added a subscriber: hiraditya.
Herald added a project: All.
lebedev.ri requested review of this revision.

This is a WIP of a somewhat more principled attempt to solve https://github.com/llvm/llvm-project/issues/59116
Admittedly, i am not familiar neither with this pass, nor with MSSA.

We have something like this:

  MDep: memcpy(tmp <- a)
  ...
  ... a is potentially modified inbetween, e.g.:
  memcpy(a <- b)
  ...
  M:    memcpy(b <- tmp)

Since we know that tmp is last modified by MDep,
what we can do, is expand MDep's memcpy into load+store pair,
and then expand M's memcpy into a store of the MDep's load:

  reload = load a
  store reload, tmp ; spill
  ...
  store reload, b   ; final store

This pattern can happen e.g. when swapping contents of the a and b,
in which case tmp might go away completely, especially if it is an alloca.

This isn't always an obvious improvement, and in general, creating large
vectors can easily cause problematic compile-time implications, so there is a
profitability heuristic: loading said vector should not require more vectors
than theoretically available on the given target.

Conceptually, does this make sense? Thoughts on the profitability check?
I suspect it's still too lax, yet we will have compile-time implications regardless.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138751

Files:
  llvm/include/llvm/Transforms/Scalar/MemCpyOptimizer.h
  llvm/lib/Transforms/Scalar/MemCpyOptimizer.cpp
  llvm/test/Transforms/MemCpyOpt/X86/lit.local.cfg
  llvm/test/Transforms/MemCpyOpt/X86/memory-swap.ll
  llvm/test/Transforms/MemCpyOpt/lifetime.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D138751.478073.patch
Type: text/x-patch
Size: 33130 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20221127/23db92fb/attachment-0001.bin>