[PATCH] D45238: MemCpyOpt does not preserve MemDep, unforunately. See PR 36965, 36964, 36940, 36944, 36943, and 36941Testcases coming.

[Daniel Berlin via Phabricator via llvm-commits]

dberlin created this revision.
dberlin added reviewers: davide, hfinkel.
Herald added a subscriber: sanjoy.

There are a number of causes here:

1. Same as pr36063, change in dependence type from local to nonlocal,

or vice versa, can't be invalidated in the cache.

2. MemDep does not do transitive cache invalidation, so

loads that would now point to a store/memcpy/etc that it has inserted,
will still point to the wrong place.

3. An unknown cause i'm still tracking down that is causing preservation failure

even when memcpyopt does nothing!

The TL;DR is that anything that moves stores across blocks probably should not be preserving memdep
(or is most likely broken right now), a least until it can be fixed.


Repository:
  rL LLVM

https://reviews.llvm.org/D45238

Files:
  lib/Transforms/Scalar/MemCpyOptimizer.cpp


Index: lib/Transforms/Scalar/MemCpyOptimizer.cpp
===================================================================
--- lib/Transforms/Scalar/MemCpyOptimizer.cpp
+++ lib/Transforms/Scalar/MemCpyOptimizer.cpp
@@ -360,7 +360,6 @@
     AU.addRequired<AAResultsWrapperPass>();
     AU.addRequired<TargetLibraryInfoWrapperPass>();
     AU.addPreserved<GlobalsAAWrapperPass>();
-    AU.addPreserved<MemoryDependenceWrapperPass>();
   }
 };
 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D45238.140883.patch
Type: text/x-patch
Size: 437 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180403/35090307/attachment.bin>