[PATCH] D155406: (WIP) [MemCpyOpt] implement multi BB stack-move optimization

[Kohei Asano via Phabricator via llvm-commits]

khei4 created this revision.
khei4 added a reviewer: nikic.
Herald added subscribers: StephenFan, JDevlieghere.
Herald added a project: All.
khei4 requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

This patch extend https://reviews.llvm.org/D153453 to muti-BB case, aims to remove memcpy like https://internals.rust-lang.org/t/the-way-to-see-how-memcpy-and-alloca-introduced-by-move-is-optimized/19148/4

1. allocas are unescaped static alloca.
2. Mod/Ref for dest doesn't exist if it's reachable to full-size copy
3. any other uses for src or dest satisfies Mod/Ref condition. `(dest Mod XOR src Ref) AND (dest Ref XOR src Mod)` ,

NOTE: for 3, this is conservative, and we can transform if all execution pass has no conflict, like cache coherency. It's safe for unescaped static contexts, if any ref, after the other one's mod and before the self-full-size Mod. This Mod could be called Def like the original pcwalton's patch <https://reviews.llvm.org/D140089>. 
To do this, we need to do user topological sort and DFS for all paths in the function. (I think). Currently, I don't know if this can be feasible.


https://reviews.llvm.org/D155406

Files:
  llvm/include/llvm/Transforms/Scalar/MemCpyOptimizer.h
  llvm/test/Transforms/MemCpyOpt/stack-move.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D155406.540812.patch
Type: text/x-patch
Size: 5815 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230716/303dae66/attachment.bin>