summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/LoopPassManager.cpp
diff options
context:
space:
mode:
authorChandler Carruth <chandlerc@gmail.com>2016-02-27 10:38:10 +0000
committerChandler Carruth <chandlerc@gmail.com>2016-02-27 10:38:10 +0000
commit2a54094d40349e283f8398bc453d7c976af63892 (patch)
tree6762721f2cb1056c9efc135dbf56727c49269823 /llvm/lib/Analysis/LoopPassManager.cpp
parent39edcd0e1d0e700b65e98e48788d8ca391c004f6 (diff)
downloadbcm5719-llvm-2a54094d40349e283f8398bc453d7c976af63892.tar.gz
bcm5719-llvm-2a54094d40349e283f8398bc453d7c976af63892.zip
[PM] Provide two templates for the two directionalities of analysis
manager proxies and use those rather than repeating their definition four times. There are real differences between the two directions: outer AMs are const and don't need to have invalidation tracked. But every proxy in a particular direction is identical except for the analysis manager type and the IR unit they proxy into. This makes them prime candidates for nice templates. I've started introducing explicit template instantiation declarations and definitions as well because we really shouldn't be emitting all this everywhere. I'm going to go back and add the same for the other templates like this in a follow-up patch. I've left the analysis manager as an opaque type rather than using two IR units and requiring it to be an AnalysisManager template specialization. I think its important that users retain the ability to provide their own custom analysis management layer and provided it has the appropriate API everything should Just Work. llvm-svn: 262127
Diffstat (limited to 'llvm/lib/Analysis/LoopPassManager.cpp')
-rw-r--r--llvm/lib/Analysis/LoopPassManager.cpp31
1 files changed, 4 insertions, 27 deletions
diff --git a/llvm/lib/Analysis/LoopPassManager.cpp b/llvm/lib/Analysis/LoopPassManager.cpp
index 1d87e07b837..fd77b786262 100644
--- a/llvm/lib/Analysis/LoopPassManager.cpp
+++ b/llvm/lib/Analysis/LoopPassManager.cpp
@@ -11,31 +11,8 @@
using namespace llvm;
-LoopAnalysisManagerFunctionProxy::Result
-LoopAnalysisManagerFunctionProxy::run(Function &F) {
- // TODO: In FunctionAnalysisManagerModuleProxy we assert that the
- // AnalysisManager is empty, but if we do that here we run afoul of the fact
- // that we still have results for previous functions alive. Should we be
- // clearing those when we finish a function?
- //assert(LAM->empty() && "Loop analyses ran prior to the function proxy!");
- return Result(*LAM);
-}
-
-LoopAnalysisManagerFunctionProxy::Result::~Result() {
- // Clear out the analysis manager if we're being destroyed -- it means we
- // didn't even see an invalidate call when we got invalidated.
- LAM->clear();
-}
-
-bool LoopAnalysisManagerFunctionProxy::Result::invalidate(
- Function &F, const PreservedAnalyses &PA) {
- // If this proxy isn't marked as preserved, then we can't even invalidate
- // individual loop analyses, there may be an invalid set of Loops in the cache
- // making it impossible to incrementally preserve them. Just clear the entire
- // manager.
- if (!PA.preserved(ID()))
- LAM->clear();
-
- // Return false to indicate that this result is still a valid proxy.
- return false;
+// Explicit instantiations for core typedef'ed templates.
+namespace llvm {
+template class InnerAnalysisManagerProxy<LoopAnalysisManager, Function>;
+template class OuterAnalysisManagerProxy<FunctionAnalysisManager, Loop>;
}
OpenPOWER on IntegriCloud