Unconditionally reset 'cache' to zero, even if we don't need to resort it.
This avoids using a dangling pointer.
Reset NumSortedEntries after restoring Cache to avoid extraneous sorts.
This fixes the reduced sqlite3 testcase, but apparently not the whole app.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62838 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/lib/Analysis/MemoryDependenceAnalysis.cpp b/lib/Analysis/MemoryDependenceAnalysis.cpp
index c84a51f..8670890 100644
--- a/lib/Analysis/MemoryDependenceAnalysis.cpp
+++ b/lib/Analysis/MemoryDependenceAnalysis.cpp
@@ -751,11 +751,9 @@
// cache remains sorted. Sort it now (if needed) so that recursive
// invocations of getNonLocalPointerDepFromBB that could reuse the cache
// value will only see properly sorted cache arrays.
- if (Cache && NumSortedEntries != Cache->size()) {
+ if (Cache && NumSortedEntries != Cache->size())
std::sort(Cache->begin(), Cache->end());
- NumSortedEntries = Cache->size();
- Cache = 0;
- }
+ Cache = 0;
// FIXME: it is entirely possible that PHI translating will end up with
// the same value. Consider PHI translating something like:
@@ -793,7 +791,8 @@
// Refresh the CacheInfo/Cache pointer so that it isn't invalidated.
CacheInfo = &NonLocalPointerDeps[CacheKey];
Cache = &CacheInfo->second;
-
+ NumSortedEntries = Cache->size();
+
// Since we did phi translation, the "Cache" set won't contain all of the
// results for the query. This is ok (we can still use it to accelerate
// specific block queries) but we can't do the fastpath "return all