diff options
author | Chandler Carruth <chandlerc@gmail.com> | 2016-02-27 10:38:10 +0000 |
---|---|---|
committer | Chandler Carruth <chandlerc@gmail.com> | 2016-02-27 10:38:10 +0000 |
commit | 2a54094d40349e283f8398bc453d7c976af63892 (patch) | |
tree | 6762721f2cb1056c9efc135dbf56727c49269823 /llvm/lib/Analysis/LoopPassManager.cpp | |
parent | 39edcd0e1d0e700b65e98e48788d8ca391c004f6 (diff) | |
download | bcm5719-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.cpp | 31 |
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>; } |