summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorChandler Carruth <chandlerc@gmail.com>2016-03-11 13:26:47 +0000
committerChandler Carruth <chandlerc@gmail.com>2016-03-11 13:26:47 +0000
commit3bc9c7fb459f72009bac39ef631117e2e8b8b149 (patch)
tree10b50b5ef54cf3b91096ecdb7c8246beb110f69d
parent4e90611ed264dc316609e508b00a5eac3c0d936e (diff)
downloadbcm5719-llvm-3bc9c7fb459f72009bac39ef631117e2e8b8b149.tar.gz
bcm5719-llvm-3bc9c7fb459f72009bac39ef631117e2e8b8b149.zip
[PM] The order of evaluation of these analyses is actually significant,
much to my horror, so use variables to fix it in place. This terrifies me. Both basic-aa and memdep will provide more precise information when the domtree and/or the loop info is available. Because of this, if your pass (like GVN) requires domtree, and then queries memdep or basic-aa, it will get more precise results. If it does this in the other order, it gets less precise results. All of the ideas I have for fixing this are, essentially, terrible. Here I've just caused us to stop having unspecified behavior as different implementations evaluate the order of these arguments differently. I'm actually rather glad that they do, or the fragility of memdep and basic-aa would have gone on unnoticed. I've left comments so we don't immediately break this again. This should fix bots whose host compilers evaluate the order of arguments differently from Clang. llvm-svn: 263231
-rw-r--r--llvm/lib/Transforms/Scalar/GVN.cpp15
1 files changed, 10 insertions, 5 deletions
diff --git a/llvm/lib/Transforms/Scalar/GVN.cpp b/llvm/lib/Transforms/Scalar/GVN.cpp
index e117b6cd3f4..49037aed56b 100644
--- a/llvm/lib/Transforms/Scalar/GVN.cpp
+++ b/llvm/lib/Transforms/Scalar/GVN.cpp
@@ -585,11 +585,16 @@ void GVN::ValueTable::verifyRemoved(const Value *V) const {
//===----------------------------------------------------------------------===//
PreservedAnalyses GVN::run(Function &F, AnalysisManager<Function> &AM) {
- bool Changed = runImpl(F, AM.getResult<AssumptionAnalysis>(F),
- AM.getResult<DominatorTreeAnalysis>(F),
- AM.getResult<TargetLibraryAnalysis>(F),
- AM.getResult<AAManager>(F),
- &AM.getResult<MemoryDependenceAnalysis>(F));
+ // FIXME: The order of evaluation of these 'getResult' calls is very
+ // significant! Re-ordering these variables will cause GVN when run alone to
+ // be less effective! We should fix memdep and basic-aa to not exhibit this
+ // behavior, but until then don't change the order here.
+ auto &AC = AM.getResult<AssumptionAnalysis>(F);
+ auto &DT = AM.getResult<DominatorTreeAnalysis>(F);
+ auto &TLI = AM.getResult<TargetLibraryAnalysis>(F);
+ auto &AA = AM.getResult<AAManager>(F);
+ auto &MemDep = AM.getResult<MemoryDependenceAnalysis>(F);
+ bool Changed = runImpl(F, AC, DT, TLI, AA, &MemDep);
return Changed ? PreservedAnalyses::none() : PreservedAnalyses::all();
}
OpenPOWER on IntegriCloud