2016-02-23 18:02:02 +08:00
|
|
|
//===- CGSCCPassManagerTest.cpp -------------------------------------------===//
|
|
|
|
|
//
|
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
|
//
|
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
#include "llvm/Analysis/CGSCCPassManager.h"
|
|
|
|
|
#include "llvm/Analysis/LazyCallGraph.h"
|
|
|
|
|
#include "llvm/AsmParser/Parser.h"
|
|
|
|
|
#include "llvm/IR/Function.h"
|
|
|
|
|
#include "llvm/IR/InstIterator.h"
|
|
|
|
|
#include "llvm/IR/LLVMContext.h"
|
|
|
|
|
#include "llvm/IR/Module.h"
|
|
|
|
|
#include "llvm/IR/PassManager.h"
|
|
|
|
|
#include "llvm/Support/SourceMgr.h"
|
|
|
|
|
#include "gtest/gtest.h"
|
|
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
2016-11-24 01:53:26 +08:00
|
|
|
class TestModuleAnalysis : public AnalysisInfoMixin<TestModuleAnalysis> {
|
2016-02-23 18:02:02 +08:00
|
|
|
public:
|
|
|
|
|
struct Result {
|
|
|
|
|
Result(int Count) : FunctionCount(Count) {}
|
|
|
|
|
int FunctionCount;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
TestModuleAnalysis(int &Runs) : Runs(Runs) {}
|
|
|
|
|
|
2016-03-11 19:05:24 +08:00
|
|
|
Result run(Module &M, ModuleAnalysisManager &AM) {
|
2016-02-23 18:02:02 +08:00
|
|
|
++Runs;
|
|
|
|
|
return Result(M.size());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
2016-11-24 01:53:26 +08:00
|
|
|
friend AnalysisInfoMixin<TestModuleAnalysis>;
|
|
|
|
|
static AnalysisKey Key;
|
2016-02-23 18:02:02 +08:00
|
|
|
|
|
|
|
|
int &Runs;
|
|
|
|
|
};
|
|
|
|
|
|
2016-11-24 01:53:26 +08:00
|
|
|
AnalysisKey TestModuleAnalysis::Key;
|
2016-02-23 18:02:02 +08:00
|
|
|
|
2016-11-24 01:53:26 +08:00
|
|
|
class TestSCCAnalysis : public AnalysisInfoMixin<TestSCCAnalysis> {
|
2016-02-23 18:02:02 +08:00
|
|
|
public:
|
|
|
|
|
struct Result {
|
|
|
|
|
Result(int Count) : FunctionCount(Count) {}
|
|
|
|
|
int FunctionCount;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
TestSCCAnalysis(int &Runs) : Runs(Runs) {}
|
|
|
|
|
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 17:37:14 +08:00
|
|
|
Result run(LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM, LazyCallGraph &) {
|
2016-02-23 18:02:02 +08:00
|
|
|
++Runs;
|
|
|
|
|
return Result(C.size());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
2016-11-24 01:53:26 +08:00
|
|
|
friend AnalysisInfoMixin<TestSCCAnalysis>;
|
|
|
|
|
static AnalysisKey Key;
|
2016-02-23 18:02:02 +08:00
|
|
|
|
|
|
|
|
int &Runs;
|
|
|
|
|
};
|
|
|
|
|
|
2016-11-24 01:53:26 +08:00
|
|
|
AnalysisKey TestSCCAnalysis::Key;
|
2016-02-23 18:02:02 +08:00
|
|
|
|
2016-11-24 01:53:26 +08:00
|
|
|
class TestFunctionAnalysis : public AnalysisInfoMixin<TestFunctionAnalysis> {
|
2016-02-23 18:02:02 +08:00
|
|
|
public:
|
|
|
|
|
struct Result {
|
|
|
|
|
Result(int Count) : InstructionCount(Count) {}
|
|
|
|
|
int InstructionCount;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
TestFunctionAnalysis(int &Runs) : Runs(Runs) {}
|
|
|
|
|
|
2016-03-11 19:05:24 +08:00
|
|
|
Result run(Function &F, FunctionAnalysisManager &AM) {
|
2016-02-23 18:02:02 +08:00
|
|
|
++Runs;
|
|
|
|
|
int Count = 0;
|
|
|
|
|
for (Instruction &I : instructions(F)) {
|
|
|
|
|
(void)I;
|
|
|
|
|
++Count;
|
|
|
|
|
}
|
|
|
|
|
return Result(Count);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
2016-11-24 01:53:26 +08:00
|
|
|
friend AnalysisInfoMixin<TestFunctionAnalysis>;
|
|
|
|
|
static AnalysisKey Key;
|
2016-02-23 18:02:02 +08:00
|
|
|
|
|
|
|
|
int &Runs;
|
|
|
|
|
};
|
|
|
|
|
|
2016-11-24 01:53:26 +08:00
|
|
|
AnalysisKey TestFunctionAnalysis::Key;
|
2016-02-23 18:02:02 +08:00
|
|
|
|
2016-11-24 01:53:26 +08:00
|
|
|
class TestImmutableFunctionAnalysis
|
|
|
|
|
: public AnalysisInfoMixin<TestImmutableFunctionAnalysis> {
|
2016-02-23 18:47:57 +08:00
|
|
|
public:
|
|
|
|
|
struct Result {
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-29 06:04:31 +08:00
|
|
|
bool invalidate(Function &, const PreservedAnalyses &,
|
|
|
|
|
FunctionAnalysisManager::Invalidator &) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2016-02-23 18:47:57 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
TestImmutableFunctionAnalysis(int &Runs) : Runs(Runs) {}
|
|
|
|
|
|
2016-03-11 19:05:24 +08:00
|
|
|
Result run(Function &F, FunctionAnalysisManager &AM) {
|
2016-02-23 18:47:57 +08:00
|
|
|
++Runs;
|
|
|
|
|
return Result();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
2016-11-24 01:53:26 +08:00
|
|
|
friend AnalysisInfoMixin<TestImmutableFunctionAnalysis>;
|
|
|
|
|
static AnalysisKey Key;
|
2016-02-23 18:47:57 +08:00
|
|
|
|
|
|
|
|
int &Runs;
|
|
|
|
|
};
|
|
|
|
|
|
2016-11-24 01:53:26 +08:00
|
|
|
AnalysisKey TestImmutableFunctionAnalysis::Key;
|
2016-02-23 18:47:57 +08:00
|
|
|
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 14:34:44 +08:00
|
|
|
struct LambdaModulePass : public PassInfoMixin<LambdaModulePass> {
|
|
|
|
|
template <typename T>
|
|
|
|
|
LambdaModulePass(T &&Arg) : Func(std::forward<T>(Arg)) {}
|
|
|
|
|
|
|
|
|
|
PreservedAnalyses run(Module &F, ModuleAnalysisManager &AM) {
|
|
|
|
|
return Func(F, AM);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
std::function<PreservedAnalyses(Module &, ModuleAnalysisManager &)> Func;
|
|
|
|
|
};
|
|
|
|
|
|
2016-09-02 09:08:04 +08:00
|
|
|
struct LambdaSCCPass : public PassInfoMixin<LambdaSCCPass> {
|
|
|
|
|
template <typename T> LambdaSCCPass(T &&Arg) : Func(std::forward<T>(Arg)) {}
|
2016-02-23 18:02:02 +08:00
|
|
|
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 17:37:14 +08:00
|
|
|
PreservedAnalyses run(LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
|
|
|
|
|
LazyCallGraph &CG, CGSCCUpdateResult &UR) {
|
2016-09-02 09:08:04 +08:00
|
|
|
return Func(C, AM, CG, UR);
|
2016-02-23 18:02:02 +08:00
|
|
|
}
|
|
|
|
|
|
2016-09-02 09:08:04 +08:00
|
|
|
std::function<PreservedAnalyses(LazyCallGraph::SCC &, CGSCCAnalysisManager &,
|
|
|
|
|
LazyCallGraph &, CGSCCUpdateResult &)>
|
|
|
|
|
Func;
|
2016-02-23 18:02:02 +08:00
|
|
|
};
|
|
|
|
|
|
2016-09-02 09:08:04 +08:00
|
|
|
struct LambdaFunctionPass : public PassInfoMixin<LambdaFunctionPass> {
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 14:34:44 +08:00
|
|
|
template <typename T>
|
|
|
|
|
LambdaFunctionPass(T &&Arg) : Func(std::forward<T>(Arg)) {}
|
2016-02-23 18:02:02 +08:00
|
|
|
|
2016-09-02 09:08:04 +08:00
|
|
|
PreservedAnalyses run(Function &F, FunctionAnalysisManager &AM) {
|
|
|
|
|
return Func(F, AM);
|
2016-02-23 18:02:02 +08:00
|
|
|
}
|
|
|
|
|
|
2016-09-02 09:08:04 +08:00
|
|
|
std::function<PreservedAnalyses(Function &, FunctionAnalysisManager &)> Func;
|
2016-02-23 18:02:02 +08:00
|
|
|
};
|
|
|
|
|
|
2016-06-28 08:38:42 +08:00
|
|
|
std::unique_ptr<Module> parseIR(const char *IR) {
|
|
|
|
|
// We just use a static context here. This is never called from multiple
|
|
|
|
|
// threads so it is harmless no matter how it is implemented. We just need
|
|
|
|
|
// the context to outlive the module which it does.
|
|
|
|
|
static LLVMContext C;
|
2016-02-23 18:02:02 +08:00
|
|
|
SMDiagnostic Err;
|
|
|
|
|
return parseAssemblyString(IR, Err, C);
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-02 09:14:05 +08:00
|
|
|
class CGSCCPassManagerTest : public ::testing::Test {
|
|
|
|
|
protected:
|
|
|
|
|
LLVMContext Context;
|
2016-09-26 14:29:21 +08:00
|
|
|
FunctionAnalysisManager FAM;
|
|
|
|
|
CGSCCAnalysisManager CGAM;
|
|
|
|
|
ModuleAnalysisManager MAM;
|
|
|
|
|
|
2016-09-02 09:14:05 +08:00
|
|
|
std::unique_ptr<Module> M;
|
|
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
CGSCCPassManagerTest()
|
2016-09-26 14:29:21 +08:00
|
|
|
: FAM(/*DebugLogging*/ true), CGAM(/*DebugLogging*/ true),
|
2016-11-28 11:40:33 +08:00
|
|
|
MAM(/*DebugLogging*/ true),
|
|
|
|
|
M(parseIR(
|
|
|
|
|
// Define a module with the following call graph, where calls go
|
|
|
|
|
// out the bottom of nodes and enter the top:
|
|
|
|
|
//
|
|
|
|
|
// f
|
|
|
|
|
// |\ _
|
|
|
|
|
// | \ / |
|
|
|
|
|
// g h1 |
|
|
|
|
|
// | | |
|
|
|
|
|
// | h2 |
|
|
|
|
|
// | | |
|
|
|
|
|
// | h3 |
|
|
|
|
|
// | / \_/
|
|
|
|
|
// |/
|
|
|
|
|
// x
|
|
|
|
|
//
|
|
|
|
|
"define void @f() {\n"
|
|
|
|
|
"entry:\n"
|
|
|
|
|
" call void @g()\n"
|
|
|
|
|
" call void @h1()\n"
|
|
|
|
|
" ret void\n"
|
|
|
|
|
"}\n"
|
|
|
|
|
"define void @g() {\n"
|
|
|
|
|
"entry:\n"
|
|
|
|
|
" call void @g()\n"
|
|
|
|
|
" call void @x()\n"
|
|
|
|
|
" ret void\n"
|
|
|
|
|
"}\n"
|
|
|
|
|
"define void @h1() {\n"
|
|
|
|
|
"entry:\n"
|
|
|
|
|
" call void @h2()\n"
|
|
|
|
|
" ret void\n"
|
|
|
|
|
"}\n"
|
|
|
|
|
"define void @h2() {\n"
|
|
|
|
|
"entry:\n"
|
|
|
|
|
" call void @h3()\n"
|
|
|
|
|
" call void @x()\n"
|
|
|
|
|
" ret void\n"
|
|
|
|
|
"}\n"
|
|
|
|
|
"define void @h3() {\n"
|
|
|
|
|
"entry:\n"
|
|
|
|
|
" call void @h1()\n"
|
|
|
|
|
" ret void\n"
|
|
|
|
|
"}\n"
|
|
|
|
|
"define void @x() {\n"
|
|
|
|
|
"entry:\n"
|
|
|
|
|
" ret void\n"
|
|
|
|
|
"}\n")) {
|
2016-09-26 14:29:21 +08:00
|
|
|
MAM.registerPass([&] { return LazyCallGraphAnalysis(); });
|
|
|
|
|
MAM.registerPass([&] { return FunctionAnalysisManagerModuleProxy(FAM); });
|
|
|
|
|
MAM.registerPass([&] { return CGSCCAnalysisManagerModuleProxy(CGAM); });
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 14:34:44 +08:00
|
|
|
CGAM.registerPass([&] { return FunctionAnalysisManagerCGSCCProxy(); });
|
2016-09-26 14:29:21 +08:00
|
|
|
CGAM.registerPass([&] { return ModuleAnalysisManagerCGSCCProxy(MAM); });
|
|
|
|
|
FAM.registerPass([&] { return CGSCCAnalysisManagerFunctionProxy(CGAM); });
|
|
|
|
|
FAM.registerPass([&] { return ModuleAnalysisManagerFunctionProxy(MAM); });
|
|
|
|
|
}
|
2016-09-02 09:14:05 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
TEST_F(CGSCCPassManagerTest, Basic) {
|
2016-02-23 18:02:02 +08:00
|
|
|
int FunctionAnalysisRuns = 0;
|
|
|
|
|
FAM.registerPass([&] { return TestFunctionAnalysis(FunctionAnalysisRuns); });
|
2016-02-23 18:47:57 +08:00
|
|
|
int ImmutableFunctionAnalysisRuns = 0;
|
|
|
|
|
FAM.registerPass([&] {
|
|
|
|
|
return TestImmutableFunctionAnalysis(ImmutableFunctionAnalysisRuns);
|
|
|
|
|
});
|
2016-02-23 18:02:02 +08:00
|
|
|
|
|
|
|
|
int SCCAnalysisRuns = 0;
|
|
|
|
|
CGAM.registerPass([&] { return TestSCCAnalysis(SCCAnalysisRuns); });
|
|
|
|
|
|
|
|
|
|
int ModuleAnalysisRuns = 0;
|
|
|
|
|
MAM.registerPass([&] { return TestModuleAnalysis(ModuleAnalysisRuns); });
|
|
|
|
|
|
|
|
|
|
ModulePassManager MPM(/*DebugLogging*/ true);
|
2016-09-02 09:08:04 +08:00
|
|
|
MPM.addPass(RequireAnalysisPass<TestModuleAnalysis, Module>());
|
2016-02-23 18:02:02 +08:00
|
|
|
|
|
|
|
|
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 14:34:44 +08:00
|
|
|
FunctionPassManager FPM1(/*DebugLogging*/ true);
|
|
|
|
|
int FunctionPassRunCount1 = 0;
|
|
|
|
|
FPM1.addPass(LambdaFunctionPass([&](Function &, FunctionAnalysisManager &) {
|
|
|
|
|
++FunctionPassRunCount1;
|
|
|
|
|
return PreservedAnalyses::none();
|
|
|
|
|
}));
|
|
|
|
|
CGPM1.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM1)));
|
|
|
|
|
|
2016-02-23 18:02:02 +08:00
|
|
|
int SCCPassRunCount1 = 0;
|
|
|
|
|
int AnalyzedInstrCount1 = 0;
|
|
|
|
|
int AnalyzedSCCFunctionCount1 = 0;
|
|
|
|
|
int AnalyzedModuleFunctionCount1 = 0;
|
2016-09-02 09:08:04 +08:00
|
|
|
CGPM1.addPass(
|
|
|
|
|
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
|
|
|
|
|
LazyCallGraph &CG, CGSCCUpdateResult &UR) {
|
|
|
|
|
++SCCPassRunCount1;
|
|
|
|
|
|
|
|
|
|
const ModuleAnalysisManager &MAM =
|
|
|
|
|
AM.getResult<ModuleAnalysisManagerCGSCCProxy>(C, CG).getManager();
|
|
|
|
|
FunctionAnalysisManager &FAM =
|
|
|
|
|
AM.getResult<FunctionAnalysisManagerCGSCCProxy>(C, CG).getManager();
|
|
|
|
|
if (TestModuleAnalysis::Result *TMA =
|
|
|
|
|
MAM.getCachedResult<TestModuleAnalysis>(
|
|
|
|
|
*C.begin()->getFunction().getParent()))
|
|
|
|
|
AnalyzedModuleFunctionCount1 += TMA->FunctionCount;
|
|
|
|
|
|
|
|
|
|
TestSCCAnalysis::Result &AR = AM.getResult<TestSCCAnalysis>(C, CG);
|
|
|
|
|
AnalyzedSCCFunctionCount1 += AR.FunctionCount;
|
|
|
|
|
for (LazyCallGraph::Node &N : C) {
|
|
|
|
|
TestFunctionAnalysis::Result &FAR =
|
|
|
|
|
FAM.getResult<TestFunctionAnalysis>(N.getFunction());
|
|
|
|
|
AnalyzedInstrCount1 += FAR.InstructionCount;
|
|
|
|
|
|
|
|
|
|
// Just ensure we get the immutable results.
|
|
|
|
|
(void)FAM.getResult<TestImmutableFunctionAnalysis>(N.getFunction());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
|
}));
|
2016-02-23 18:02:02 +08:00
|
|
|
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 14:34:44 +08:00
|
|
|
FunctionPassManager FPM2(/*DebugLogging*/ true);
|
|
|
|
|
int FunctionPassRunCount2 = 0;
|
|
|
|
|
FPM2.addPass(LambdaFunctionPass([&](Function &, FunctionAnalysisManager &) {
|
|
|
|
|
++FunctionPassRunCount2;
|
|
|
|
|
return PreservedAnalyses::none();
|
2016-09-02 09:08:04 +08:00
|
|
|
}));
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 14:34:44 +08:00
|
|
|
CGPM1.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM2)));
|
|
|
|
|
|
2016-02-23 18:02:02 +08:00
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
|
|
|
|
|
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 14:34:44 +08:00
|
|
|
FunctionPassManager FPM3(/*DebugLogging*/ true);
|
|
|
|
|
int FunctionPassRunCount3 = 0;
|
|
|
|
|
FPM3.addPass(LambdaFunctionPass([&](Function &, FunctionAnalysisManager &) {
|
|
|
|
|
++FunctionPassRunCount3;
|
|
|
|
|
return PreservedAnalyses::none();
|
|
|
|
|
}));
|
|
|
|
|
MPM.addPass(createModuleToFunctionPassAdaptor(std::move(FPM3)));
|
|
|
|
|
|
2016-03-11 19:05:24 +08:00
|
|
|
MPM.run(*M, MAM);
|
2016-02-23 18:02:02 +08:00
|
|
|
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 14:34:44 +08:00
|
|
|
EXPECT_EQ(4, SCCPassRunCount1);
|
|
|
|
|
EXPECT_EQ(6, FunctionPassRunCount1);
|
|
|
|
|
EXPECT_EQ(6, FunctionPassRunCount2);
|
|
|
|
|
EXPECT_EQ(6, FunctionPassRunCount3);
|
|
|
|
|
|
2016-02-23 18:02:02 +08:00
|
|
|
EXPECT_EQ(1, ModuleAnalysisRuns);
|
|
|
|
|
EXPECT_EQ(4, SCCAnalysisRuns);
|
|
|
|
|
EXPECT_EQ(6, FunctionAnalysisRuns);
|
2016-02-23 18:47:57 +08:00
|
|
|
EXPECT_EQ(6, ImmutableFunctionAnalysisRuns);
|
2016-02-23 18:02:02 +08:00
|
|
|
|
|
|
|
|
EXPECT_EQ(14, AnalyzedInstrCount1);
|
|
|
|
|
EXPECT_EQ(6, AnalyzedSCCFunctionCount1);
|
|
|
|
|
EXPECT_EQ(4 * 6, AnalyzedModuleFunctionCount1);
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-26 12:01:55 +08:00
|
|
|
// Test that an SCC pass which fails to preserve a module analysis does in fact
|
|
|
|
|
// invalidate that module analysis.
|
|
|
|
|
TEST_F(CGSCCPassManagerTest, TestSCCPassInvalidatesModuleAnalysis) {
|
|
|
|
|
int ModuleAnalysisRuns = 0;
|
|
|
|
|
MAM.registerPass([&] { return TestModuleAnalysis(ModuleAnalysisRuns); });
|
|
|
|
|
|
|
|
|
|
ModulePassManager MPM(/*DebugLogging*/ true);
|
|
|
|
|
MPM.addPass(RequireAnalysisPass<TestModuleAnalysis, Module>());
|
|
|
|
|
|
|
|
|
|
// The first CGSCC run we preserve everything and make sure that works and
|
|
|
|
|
// the module analysis is available in the second CGSCC run from the one
|
|
|
|
|
// required module pass above.
|
|
|
|
|
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
|
|
|
|
|
int CountFoundModuleAnalysis1 = 0;
|
|
|
|
|
CGPM1.addPass(
|
|
|
|
|
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
|
|
|
|
|
LazyCallGraph &CG, CGSCCUpdateResult &UR) {
|
|
|
|
|
const auto &MAM =
|
|
|
|
|
AM.getResult<ModuleAnalysisManagerCGSCCProxy>(C, CG).getManager();
|
|
|
|
|
auto *TMA = MAM.getCachedResult<TestModuleAnalysis>(
|
|
|
|
|
*C.begin()->getFunction().getParent());
|
|
|
|
|
|
|
|
|
|
if (TMA)
|
|
|
|
|
++CountFoundModuleAnalysis1;
|
|
|
|
|
|
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
|
}));
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
|
|
|
|
|
|
|
|
|
|
// The second CGSCC run checks that the module analysis got preserved the
|
|
|
|
|
// previous time and in one SCC fails to preserve it.
|
|
|
|
|
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
|
|
|
|
|
int CountFoundModuleAnalysis2 = 0;
|
|
|
|
|
CGPM2.addPass(
|
|
|
|
|
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
|
|
|
|
|
LazyCallGraph &CG, CGSCCUpdateResult &UR) {
|
|
|
|
|
const auto &MAM =
|
|
|
|
|
AM.getResult<ModuleAnalysisManagerCGSCCProxy>(C, CG).getManager();
|
|
|
|
|
auto *TMA = MAM.getCachedResult<TestModuleAnalysis>(
|
|
|
|
|
*C.begin()->getFunction().getParent());
|
|
|
|
|
|
|
|
|
|
if (TMA)
|
|
|
|
|
++CountFoundModuleAnalysis2;
|
|
|
|
|
|
|
|
|
|
// Only fail to preserve analyses on one SCC and make sure that gets
|
|
|
|
|
// propagated.
|
|
|
|
|
return C.getName() == "(g)" ? PreservedAnalyses::none()
|
|
|
|
|
: PreservedAnalyses::all();
|
|
|
|
|
}));
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
|
|
|
|
|
|
|
|
|
|
// The third CGSCC run should fail to find a cached module analysis as it
|
|
|
|
|
// should have been invalidated by the above CGSCC run.
|
|
|
|
|
CGSCCPassManager CGPM3(/*DebugLogging*/ true);
|
|
|
|
|
int CountFoundModuleAnalysis3 = 0;
|
|
|
|
|
CGPM3.addPass(
|
|
|
|
|
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
|
|
|
|
|
LazyCallGraph &CG, CGSCCUpdateResult &UR) {
|
|
|
|
|
const auto &MAM =
|
|
|
|
|
AM.getResult<ModuleAnalysisManagerCGSCCProxy>(C, CG).getManager();
|
|
|
|
|
auto *TMA = MAM.getCachedResult<TestModuleAnalysis>(
|
|
|
|
|
*C.begin()->getFunction().getParent());
|
|
|
|
|
|
|
|
|
|
if (TMA)
|
|
|
|
|
++CountFoundModuleAnalysis3;
|
|
|
|
|
|
|
|
|
|
return PreservedAnalyses::none();
|
|
|
|
|
}));
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM3)));
|
|
|
|
|
|
|
|
|
|
MPM.run(*M, MAM);
|
|
|
|
|
|
|
|
|
|
EXPECT_EQ(1, ModuleAnalysisRuns);
|
|
|
|
|
EXPECT_EQ(4, CountFoundModuleAnalysis1);
|
|
|
|
|
EXPECT_EQ(4, CountFoundModuleAnalysis2);
|
|
|
|
|
EXPECT_EQ(0, CountFoundModuleAnalysis3);
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-26 12:17:12 +08:00
|
|
|
// Similar to the above, but test that this works for function passes embedded
|
|
|
|
|
// *within* a CGSCC layer.
|
|
|
|
|
TEST_F(CGSCCPassManagerTest, TestFunctionPassInsideCGSCCInvalidatesModuleAnalysis) {
|
|
|
|
|
int ModuleAnalysisRuns = 0;
|
|
|
|
|
MAM.registerPass([&] { return TestModuleAnalysis(ModuleAnalysisRuns); });
|
|
|
|
|
|
|
|
|
|
ModulePassManager MPM(/*DebugLogging*/ true);
|
|
|
|
|
MPM.addPass(RequireAnalysisPass<TestModuleAnalysis, Module>());
|
|
|
|
|
|
|
|
|
|
// The first run we preserve everything and make sure that works and the
|
|
|
|
|
// module analysis is available in the second run from the one required
|
|
|
|
|
// module pass above.
|
|
|
|
|
FunctionPassManager FPM1(/*DebugLogging*/ true);
|
|
|
|
|
// Start true and mark false if we ever failed to find a module analysis
|
|
|
|
|
// because we expect this to succeed for each SCC.
|
|
|
|
|
bool FoundModuleAnalysis1 = true;
|
|
|
|
|
FPM1.addPass(
|
|
|
|
|
LambdaFunctionPass([&](Function &F, FunctionAnalysisManager &AM) {
|
|
|
|
|
const auto &MAM =
|
|
|
|
|
AM.getResult<ModuleAnalysisManagerFunctionProxy>(F).getManager();
|
|
|
|
|
auto *TMA = MAM.getCachedResult<TestModuleAnalysis>(*F.getParent());
|
|
|
|
|
|
|
|
|
|
if (!TMA)
|
|
|
|
|
FoundModuleAnalysis1 = false;
|
|
|
|
|
|
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
|
}));
|
|
|
|
|
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
|
|
|
|
|
CGPM1.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM1)));
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
|
|
|
|
|
|
|
|
|
|
// The second run checks that the module analysis got preserved the previous
|
|
|
|
|
// time and in one function fails to preserve it.
|
|
|
|
|
FunctionPassManager FPM2(/*DebugLogging*/ true);
|
|
|
|
|
// Again, start true and mark false if we ever failed to find a module analysis
|
|
|
|
|
// because we expect this to succeed for each SCC.
|
|
|
|
|
bool FoundModuleAnalysis2 = true;
|
|
|
|
|
FPM2.addPass(
|
|
|
|
|
LambdaFunctionPass([&](Function &F, FunctionAnalysisManager &AM) {
|
|
|
|
|
const auto &MAM =
|
|
|
|
|
AM.getResult<ModuleAnalysisManagerFunctionProxy>(F).getManager();
|
|
|
|
|
auto *TMA = MAM.getCachedResult<TestModuleAnalysis>(*F.getParent());
|
|
|
|
|
|
|
|
|
|
if (!TMA)
|
|
|
|
|
FoundModuleAnalysis2 = false;
|
|
|
|
|
|
|
|
|
|
// Only fail to preserve analyses on one SCC and make sure that gets
|
|
|
|
|
// propagated.
|
|
|
|
|
return F.getName() == "h2" ? PreservedAnalyses::none()
|
|
|
|
|
: PreservedAnalyses::all();
|
|
|
|
|
}));
|
|
|
|
|
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
|
|
|
|
|
CGPM2.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM2)));
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
|
|
|
|
|
|
|
|
|
|
// The third run should fail to find a cached module analysis as it should
|
|
|
|
|
// have been invalidated by the above run.
|
|
|
|
|
FunctionPassManager FPM3(/*DebugLogging*/ true);
|
|
|
|
|
// Start false and mark true if we ever *succeeded* to find a module
|
|
|
|
|
// analysis, as we expect this to fail for every function.
|
|
|
|
|
bool FoundModuleAnalysis3 = false;
|
|
|
|
|
FPM3.addPass(
|
|
|
|
|
LambdaFunctionPass([&](Function &F, FunctionAnalysisManager &AM) {
|
|
|
|
|
const auto &MAM =
|
|
|
|
|
AM.getResult<ModuleAnalysisManagerFunctionProxy>(F).getManager();
|
|
|
|
|
auto *TMA = MAM.getCachedResult<TestModuleAnalysis>(*F.getParent());
|
|
|
|
|
|
|
|
|
|
if (TMA)
|
|
|
|
|
FoundModuleAnalysis3 = true;
|
|
|
|
|
|
|
|
|
|
return PreservedAnalyses::none();
|
|
|
|
|
}));
|
|
|
|
|
CGSCCPassManager CGPM3(/*DebugLogging*/ true);
|
|
|
|
|
CGPM3.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM3)));
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM3)));
|
|
|
|
|
|
|
|
|
|
MPM.run(*M, MAM);
|
|
|
|
|
|
|
|
|
|
EXPECT_EQ(1, ModuleAnalysisRuns);
|
|
|
|
|
EXPECT_TRUE(FoundModuleAnalysis1);
|
|
|
|
|
EXPECT_TRUE(FoundModuleAnalysis2);
|
|
|
|
|
EXPECT_FALSE(FoundModuleAnalysis3);
|
|
|
|
|
}
|
|
|
|
|
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 14:34:44 +08:00
|
|
|
// Test that a Module pass which fails to preserve an SCC analysis in fact
|
|
|
|
|
// invalidates that analysis.
|
|
|
|
|
TEST_F(CGSCCPassManagerTest, TestModulePassInvalidatesSCCAnalysis) {
|
|
|
|
|
int SCCAnalysisRuns = 0;
|
|
|
|
|
CGAM.registerPass([&] { return TestSCCAnalysis(SCCAnalysisRuns); });
|
|
|
|
|
|
|
|
|
|
ModulePassManager MPM(/*DebugLogging*/ true);
|
|
|
|
|
|
|
|
|
|
// First force the analysis to be run.
|
|
|
|
|
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
|
|
|
|
|
CGPM1.addPass(RequireAnalysisPass<TestSCCAnalysis, LazyCallGraph::SCC,
|
|
|
|
|
CGSCCAnalysisManager, LazyCallGraph &,
|
|
|
|
|
CGSCCUpdateResult &>());
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
|
|
|
|
|
|
|
|
|
|
// Now run a module pass that preserves the LazyCallGraph and the proxy but
|
|
|
|
|
// not the SCC analysis.
|
|
|
|
|
MPM.addPass(LambdaModulePass([&](Module &M, ModuleAnalysisManager &) {
|
|
|
|
|
PreservedAnalyses PA;
|
|
|
|
|
PA.preserve<LazyCallGraphAnalysis>();
|
|
|
|
|
PA.preserve<CGSCCAnalysisManagerModuleProxy>();
|
|
|
|
|
PA.preserve<FunctionAnalysisManagerModuleProxy>();
|
|
|
|
|
return PA;
|
|
|
|
|
}));
|
|
|
|
|
|
|
|
|
|
// And now a second CGSCC run which requires the SCC analysis again. This
|
|
|
|
|
// will trigger re-running it.
|
|
|
|
|
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
|
|
|
|
|
CGPM2.addPass(RequireAnalysisPass<TestSCCAnalysis, LazyCallGraph::SCC,
|
|
|
|
|
CGSCCAnalysisManager, LazyCallGraph &,
|
|
|
|
|
CGSCCUpdateResult &>());
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
|
|
|
|
|
|
|
|
|
|
MPM.run(*M, MAM);
|
|
|
|
|
// Two runs and four SCCs.
|
|
|
|
|
EXPECT_EQ(2 * 4, SCCAnalysisRuns);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Check that marking the SCC analysis preserved is sufficient to avoid
|
|
|
|
|
// invaliadtion. This should only run the analysis once for each SCC.
|
|
|
|
|
TEST_F(CGSCCPassManagerTest, TestModulePassCanPreserveSCCAnalysis) {
|
|
|
|
|
int SCCAnalysisRuns = 0;
|
|
|
|
|
CGAM.registerPass([&] { return TestSCCAnalysis(SCCAnalysisRuns); });
|
|
|
|
|
|
|
|
|
|
ModulePassManager MPM(/*DebugLogging*/ true);
|
|
|
|
|
|
|
|
|
|
// First force the analysis to be run.
|
|
|
|
|
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
|
|
|
|
|
CGPM1.addPass(RequireAnalysisPass<TestSCCAnalysis, LazyCallGraph::SCC,
|
|
|
|
|
CGSCCAnalysisManager, LazyCallGraph &,
|
|
|
|
|
CGSCCUpdateResult &>());
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
|
|
|
|
|
|
|
|
|
|
// Now run a module pass that preserves each of the necessary components
|
|
|
|
|
// (but not everything).
|
|
|
|
|
MPM.addPass(LambdaModulePass([&](Module &M, ModuleAnalysisManager &) {
|
|
|
|
|
PreservedAnalyses PA;
|
|
|
|
|
PA.preserve<LazyCallGraphAnalysis>();
|
|
|
|
|
PA.preserve<CGSCCAnalysisManagerModuleProxy>();
|
|
|
|
|
PA.preserve<FunctionAnalysisManagerModuleProxy>();
|
|
|
|
|
PA.preserve<TestSCCAnalysis>();
|
|
|
|
|
return PA;
|
|
|
|
|
}));
|
|
|
|
|
|
|
|
|
|
// And now a second CGSCC run which requires the SCC analysis again but find
|
|
|
|
|
// it in the cache.
|
|
|
|
|
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
|
|
|
|
|
CGPM2.addPass(RequireAnalysisPass<TestSCCAnalysis, LazyCallGraph::SCC,
|
|
|
|
|
CGSCCAnalysisManager, LazyCallGraph &,
|
|
|
|
|
CGSCCUpdateResult &>());
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
|
|
|
|
|
|
|
|
|
|
MPM.run(*M, MAM);
|
|
|
|
|
// Four SCCs
|
|
|
|
|
EXPECT_EQ(4, SCCAnalysisRuns);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Check that even when the analysis is preserved, if the SCC information isn't
|
|
|
|
|
// we still nuke things because the SCC keys could change.
|
|
|
|
|
TEST_F(CGSCCPassManagerTest, TestModulePassInvalidatesSCCAnalysisOnCGChange) {
|
|
|
|
|
int SCCAnalysisRuns = 0;
|
|
|
|
|
CGAM.registerPass([&] { return TestSCCAnalysis(SCCAnalysisRuns); });
|
|
|
|
|
|
|
|
|
|
ModulePassManager MPM(/*DebugLogging*/ true);
|
|
|
|
|
|
|
|
|
|
// First force the analysis to be run.
|
|
|
|
|
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
|
|
|
|
|
CGPM1.addPass(RequireAnalysisPass<TestSCCAnalysis, LazyCallGraph::SCC,
|
|
|
|
|
CGSCCAnalysisManager, LazyCallGraph &,
|
|
|
|
|
CGSCCUpdateResult &>());
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
|
|
|
|
|
|
|
|
|
|
// Now run a module pass that preserves the analysis but not the call
|
|
|
|
|
// graph or proxy.
|
|
|
|
|
MPM.addPass(LambdaModulePass([&](Module &M, ModuleAnalysisManager &) {
|
|
|
|
|
PreservedAnalyses PA;
|
|
|
|
|
PA.preserve<TestSCCAnalysis>();
|
|
|
|
|
return PA;
|
|
|
|
|
}));
|
|
|
|
|
|
|
|
|
|
// And now a second CGSCC run which requires the SCC analysis again.
|
|
|
|
|
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
|
|
|
|
|
CGPM2.addPass(RequireAnalysisPass<TestSCCAnalysis, LazyCallGraph::SCC,
|
|
|
|
|
CGSCCAnalysisManager, LazyCallGraph &,
|
|
|
|
|
CGSCCUpdateResult &>());
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
|
|
|
|
|
|
|
|
|
|
MPM.run(*M, MAM);
|
|
|
|
|
// Two runs and four SCCs.
|
|
|
|
|
EXPECT_EQ(2 * 4, SCCAnalysisRuns);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test that an SCC pass which fails to preserve a Function analysis in fact
|
|
|
|
|
// invalidates that analysis.
|
|
|
|
|
TEST_F(CGSCCPassManagerTest, TestSCCPassInvalidatesFunctionAnalysis) {
|
|
|
|
|
int FunctionAnalysisRuns = 0;
|
|
|
|
|
FAM.registerPass([&] { return TestFunctionAnalysis(FunctionAnalysisRuns); });
|
|
|
|
|
|
|
|
|
|
// Create a very simple module with a single function and SCC to make testing
|
|
|
|
|
// these issues much easier.
|
|
|
|
|
std::unique_ptr<Module> M = parseIR("declare void @g()\n"
|
|
|
|
|
"declare void @h()\n"
|
|
|
|
|
"define void @f() {\n"
|
|
|
|
|
"entry:\n"
|
|
|
|
|
" call void @g()\n"
|
|
|
|
|
" call void @h()\n"
|
|
|
|
|
" ret void\n"
|
|
|
|
|
"}\n");
|
|
|
|
|
|
|
|
|
|
CGSCCPassManager CGPM(/*DebugLogging*/ true);
|
|
|
|
|
|
|
|
|
|
// First force the analysis to be run.
|
|
|
|
|
FunctionPassManager FPM1(/*DebugLogging*/ true);
|
|
|
|
|
FPM1.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
|
|
|
|
|
CGPM.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM1)));
|
|
|
|
|
|
|
|
|
|
// Now run a module pass that preserves the LazyCallGraph and proxy but not
|
|
|
|
|
// the SCC analysis.
|
|
|
|
|
CGPM.addPass(LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &,
|
|
|
|
|
LazyCallGraph &, CGSCCUpdateResult &) {
|
|
|
|
|
PreservedAnalyses PA;
|
|
|
|
|
PA.preserve<LazyCallGraphAnalysis>();
|
|
|
|
|
return PA;
|
|
|
|
|
}));
|
|
|
|
|
|
|
|
|
|
// And now a second CGSCC run which requires the SCC analysis again. This
|
|
|
|
|
// will trigger re-running it.
|
|
|
|
|
FunctionPassManager FPM2(/*DebugLogging*/ true);
|
|
|
|
|
FPM2.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
|
|
|
|
|
CGPM.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM2)));
|
|
|
|
|
|
|
|
|
|
ModulePassManager MPM(/*DebugLogging*/ true);
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM)));
|
|
|
|
|
MPM.run(*M, MAM);
|
|
|
|
|
EXPECT_EQ(2, FunctionAnalysisRuns);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Check that marking the SCC analysis preserved is sufficient. This should
|
|
|
|
|
// only run the analysis once the SCC.
|
|
|
|
|
TEST_F(CGSCCPassManagerTest, TestSCCPassCanPreserveFunctionAnalysis) {
|
|
|
|
|
int FunctionAnalysisRuns = 0;
|
|
|
|
|
FAM.registerPass([&] { return TestFunctionAnalysis(FunctionAnalysisRuns); });
|
|
|
|
|
|
|
|
|
|
// Create a very simple module with a single function and SCC to make testing
|
|
|
|
|
// these issues much easier.
|
|
|
|
|
std::unique_ptr<Module> M = parseIR("declare void @g()\n"
|
|
|
|
|
"declare void @h()\n"
|
|
|
|
|
"define void @f() {\n"
|
|
|
|
|
"entry:\n"
|
|
|
|
|
" call void @g()\n"
|
|
|
|
|
" call void @h()\n"
|
|
|
|
|
" ret void\n"
|
|
|
|
|
"}\n");
|
|
|
|
|
|
|
|
|
|
CGSCCPassManager CGPM(/*DebugLogging*/ true);
|
|
|
|
|
|
|
|
|
|
// First force the analysis to be run.
|
|
|
|
|
FunctionPassManager FPM1(/*DebugLogging*/ true);
|
|
|
|
|
FPM1.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
|
|
|
|
|
CGPM.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM1)));
|
|
|
|
|
|
|
|
|
|
// Now run a module pass that preserves each of the necessary components
|
|
|
|
|
// (but
|
|
|
|
|
// not everything).
|
|
|
|
|
CGPM.addPass(LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &,
|
|
|
|
|
LazyCallGraph &, CGSCCUpdateResult &) {
|
|
|
|
|
PreservedAnalyses PA;
|
|
|
|
|
PA.preserve<LazyCallGraphAnalysis>();
|
[PM] Finish implementing and fix a chain of bugs uncovered by testing
the invalidation propagation logic from an SCC to a Function.
I wrote the infrastructure to test this but didn't actually use it in
the unit test where it was designed to be used. =[ My bad. Once
I actually added it to the test case I discovered that it also hadn't
been properly implemented, so I've implemented it. The logic in the FAM
proxy for an SCC pass to propagate invalidation follows the same ideas
as the FAM proxy for a Module pass, but the implementation is a bit
different to reflect the fact that it is forwarding just for an SCC.
However, implementing this correctly uncovered a surprising "bug" (it
was conservatively correct but relatively very expensive) in how we
handle invalidation when splitting one SCC into multiple SCCs. We did an
eager invalidation when in reality we should be deferring invaliadtion
for the *current* SCC to the CGSCC pass manager and just invaliating the
newly constructed SCCs. Otherwise we end up invalidating too much too
soon. This was exposed by the inliner test case that I've updated. Now,
we invalidate *just* the split off '(test1_f)' SCC when doing the CG
update, and then the inliner finishes and invalidates the '(test1_g,
test1_h)' SCC's analyses. The first few attempts at fixing this hit
still more bugs, but all of those are covered by existing tests. For
example, the inliner should also preserve the FAM proxy to avoid
unnecesasry invalidation, and this is safe because the CG update
routines it uses handle any necessary adjustments to the FAM proxy.
Finally, the unittests for the CGSCC pass manager needed a bunch of
updates where we weren't correctly preserving the FAM proxy because it
hadn't been fully implemented and failing to preserve it didn't matter.
Note that this doesn't yet fix the current crasher due to MemSSA finding
a stale dominator tree, but without this the fix to that crasher doesn't
really make any sense when testing because it relies on the proxy
behavior.
llvm-svn: 307487
2017-07-09 11:59:31 +08:00
|
|
|
PA.preserve<FunctionAnalysisManagerCGSCCProxy>();
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 14:34:44 +08:00
|
|
|
PA.preserve<TestFunctionAnalysis>();
|
|
|
|
|
return PA;
|
|
|
|
|
}));
|
|
|
|
|
|
|
|
|
|
// And now a second CGSCC run which requires the SCC analysis again but find
|
|
|
|
|
// it in the cache.
|
|
|
|
|
FunctionPassManager FPM2(/*DebugLogging*/ true);
|
|
|
|
|
FPM2.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
|
|
|
|
|
CGPM.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM2)));
|
|
|
|
|
|
|
|
|
|
ModulePassManager MPM(/*DebugLogging*/ true);
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM)));
|
|
|
|
|
MPM.run(*M, MAM);
|
|
|
|
|
EXPECT_EQ(1, FunctionAnalysisRuns);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Note that there is no test for invalidating the call graph or other
|
|
|
|
|
// structure with an SCC pass because there is no mechanism to do that from
|
|
|
|
|
// withinsuch a pass. Instead, such a pass has to directly update the call
|
|
|
|
|
// graph structure.
|
|
|
|
|
|
|
|
|
|
// Test that a madule pass invalidates function analyses when the CGSCC proxies
|
|
|
|
|
// and pass manager.
|
|
|
|
|
TEST_F(CGSCCPassManagerTest,
|
|
|
|
|
TestModulePassInvalidatesFunctionAnalysisNestedInCGSCC) {
|
|
|
|
|
MAM.registerPass([&] { return LazyCallGraphAnalysis(); });
|
|
|
|
|
|
|
|
|
|
int FunctionAnalysisRuns = 0;
|
|
|
|
|
FAM.registerPass([&] { return TestFunctionAnalysis(FunctionAnalysisRuns); });
|
|
|
|
|
|
|
|
|
|
ModulePassManager MPM(/*DebugLogging*/ true);
|
|
|
|
|
|
|
|
|
|
// First force the analysis to be run.
|
|
|
|
|
FunctionPassManager FPM1(/*DebugLogging*/ true);
|
|
|
|
|
FPM1.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
|
|
|
|
|
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
|
|
|
|
|
CGPM1.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM1)));
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
|
|
|
|
|
|
[PM] Finish implementing and fix a chain of bugs uncovered by testing
the invalidation propagation logic from an SCC to a Function.
I wrote the infrastructure to test this but didn't actually use it in
the unit test where it was designed to be used. =[ My bad. Once
I actually added it to the test case I discovered that it also hadn't
been properly implemented, so I've implemented it. The logic in the FAM
proxy for an SCC pass to propagate invalidation follows the same ideas
as the FAM proxy for a Module pass, but the implementation is a bit
different to reflect the fact that it is forwarding just for an SCC.
However, implementing this correctly uncovered a surprising "bug" (it
was conservatively correct but relatively very expensive) in how we
handle invalidation when splitting one SCC into multiple SCCs. We did an
eager invalidation when in reality we should be deferring invaliadtion
for the *current* SCC to the CGSCC pass manager and just invaliating the
newly constructed SCCs. Otherwise we end up invalidating too much too
soon. This was exposed by the inliner test case that I've updated. Now,
we invalidate *just* the split off '(test1_f)' SCC when doing the CG
update, and then the inliner finishes and invalidates the '(test1_g,
test1_h)' SCC's analyses. The first few attempts at fixing this hit
still more bugs, but all of those are covered by existing tests. For
example, the inliner should also preserve the FAM proxy to avoid
unnecesasry invalidation, and this is safe because the CG update
routines it uses handle any necessary adjustments to the FAM proxy.
Finally, the unittests for the CGSCC pass manager needed a bunch of
updates where we weren't correctly preserving the FAM proxy because it
hadn't been fully implemented and failing to preserve it didn't matter.
Note that this doesn't yet fix the current crasher due to MemSSA finding
a stale dominator tree, but without this the fix to that crasher doesn't
really make any sense when testing because it relies on the proxy
behavior.
llvm-svn: 307487
2017-07-09 11:59:31 +08:00
|
|
|
// Now run a module pass that preserves the LazyCallGraph and proxies but not
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 14:34:44 +08:00
|
|
|
// the Function analysis.
|
|
|
|
|
MPM.addPass(LambdaModulePass([&](Module &M, ModuleAnalysisManager &) {
|
|
|
|
|
PreservedAnalyses PA;
|
|
|
|
|
PA.preserve<LazyCallGraphAnalysis>();
|
|
|
|
|
PA.preserve<CGSCCAnalysisManagerModuleProxy>();
|
[PM] Finish implementing and fix a chain of bugs uncovered by testing
the invalidation propagation logic from an SCC to a Function.
I wrote the infrastructure to test this but didn't actually use it in
the unit test where it was designed to be used. =[ My bad. Once
I actually added it to the test case I discovered that it also hadn't
been properly implemented, so I've implemented it. The logic in the FAM
proxy for an SCC pass to propagate invalidation follows the same ideas
as the FAM proxy for a Module pass, but the implementation is a bit
different to reflect the fact that it is forwarding just for an SCC.
However, implementing this correctly uncovered a surprising "bug" (it
was conservatively correct but relatively very expensive) in how we
handle invalidation when splitting one SCC into multiple SCCs. We did an
eager invalidation when in reality we should be deferring invaliadtion
for the *current* SCC to the CGSCC pass manager and just invaliating the
newly constructed SCCs. Otherwise we end up invalidating too much too
soon. This was exposed by the inliner test case that I've updated. Now,
we invalidate *just* the split off '(test1_f)' SCC when doing the CG
update, and then the inliner finishes and invalidates the '(test1_g,
test1_h)' SCC's analyses. The first few attempts at fixing this hit
still more bugs, but all of those are covered by existing tests. For
example, the inliner should also preserve the FAM proxy to avoid
unnecesasry invalidation, and this is safe because the CG update
routines it uses handle any necessary adjustments to the FAM proxy.
Finally, the unittests for the CGSCC pass manager needed a bunch of
updates where we weren't correctly preserving the FAM proxy because it
hadn't been fully implemented and failing to preserve it didn't matter.
Note that this doesn't yet fix the current crasher due to MemSSA finding
a stale dominator tree, but without this the fix to that crasher doesn't
really make any sense when testing because it relies on the proxy
behavior.
llvm-svn: 307487
2017-07-09 11:59:31 +08:00
|
|
|
PA.preserve<FunctionAnalysisManagerCGSCCProxy>();
|
|
|
|
|
PA.preserve<FunctionAnalysisManagerModuleProxy>();
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 14:34:44 +08:00
|
|
|
return PA;
|
|
|
|
|
}));
|
|
|
|
|
|
|
|
|
|
// And now a second CGSCC run which requires the SCC analysis again. This
|
|
|
|
|
// will trigger re-running it.
|
|
|
|
|
FunctionPassManager FPM2(/*DebugLogging*/ true);
|
|
|
|
|
FPM2.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
|
|
|
|
|
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
|
|
|
|
|
CGPM2.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM2)));
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
|
|
|
|
|
|
|
|
|
|
MPM.run(*M, MAM);
|
|
|
|
|
// Two runs and 6 functions.
|
|
|
|
|
EXPECT_EQ(2 * 6, FunctionAnalysisRuns);
|
|
|
|
|
}
|
|
|
|
|
|
[PM] Finish implementing and fix a chain of bugs uncovered by testing
the invalidation propagation logic from an SCC to a Function.
I wrote the infrastructure to test this but didn't actually use it in
the unit test where it was designed to be used. =[ My bad. Once
I actually added it to the test case I discovered that it also hadn't
been properly implemented, so I've implemented it. The logic in the FAM
proxy for an SCC pass to propagate invalidation follows the same ideas
as the FAM proxy for a Module pass, but the implementation is a bit
different to reflect the fact that it is forwarding just for an SCC.
However, implementing this correctly uncovered a surprising "bug" (it
was conservatively correct but relatively very expensive) in how we
handle invalidation when splitting one SCC into multiple SCCs. We did an
eager invalidation when in reality we should be deferring invaliadtion
for the *current* SCC to the CGSCC pass manager and just invaliating the
newly constructed SCCs. Otherwise we end up invalidating too much too
soon. This was exposed by the inliner test case that I've updated. Now,
we invalidate *just* the split off '(test1_f)' SCC when doing the CG
update, and then the inliner finishes and invalidates the '(test1_g,
test1_h)' SCC's analyses. The first few attempts at fixing this hit
still more bugs, but all of those are covered by existing tests. For
example, the inliner should also preserve the FAM proxy to avoid
unnecesasry invalidation, and this is safe because the CG update
routines it uses handle any necessary adjustments to the FAM proxy.
Finally, the unittests for the CGSCC pass manager needed a bunch of
updates where we weren't correctly preserving the FAM proxy because it
hadn't been fully implemented and failing to preserve it didn't matter.
Note that this doesn't yet fix the current crasher due to MemSSA finding
a stale dominator tree, but without this the fix to that crasher doesn't
really make any sense when testing because it relies on the proxy
behavior.
llvm-svn: 307487
2017-07-09 11:59:31 +08:00
|
|
|
// Check that by marking the function pass and proxies as preserved, this
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 14:34:44 +08:00
|
|
|
// propagates all the way through.
|
|
|
|
|
TEST_F(CGSCCPassManagerTest,
|
|
|
|
|
TestModulePassCanPreserveFunctionAnalysisNestedInCGSCC) {
|
|
|
|
|
MAM.registerPass([&] { return LazyCallGraphAnalysis(); });
|
|
|
|
|
|
|
|
|
|
int FunctionAnalysisRuns = 0;
|
|
|
|
|
FAM.registerPass([&] { return TestFunctionAnalysis(FunctionAnalysisRuns); });
|
|
|
|
|
|
|
|
|
|
ModulePassManager MPM(/*DebugLogging*/ true);
|
|
|
|
|
|
|
|
|
|
// First force the analysis to be run.
|
|
|
|
|
FunctionPassManager FPM1(/*DebugLogging*/ true);
|
|
|
|
|
FPM1.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
|
|
|
|
|
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
|
|
|
|
|
CGPM1.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM1)));
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
|
|
|
|
|
|
|
|
|
|
// Now run a module pass that preserves the LazyCallGraph, the proxy, and
|
|
|
|
|
// the Function analysis.
|
|
|
|
|
MPM.addPass(LambdaModulePass([&](Module &M, ModuleAnalysisManager &) {
|
|
|
|
|
PreservedAnalyses PA;
|
|
|
|
|
PA.preserve<LazyCallGraphAnalysis>();
|
|
|
|
|
PA.preserve<CGSCCAnalysisManagerModuleProxy>();
|
[PM] Finish implementing and fix a chain of bugs uncovered by testing
the invalidation propagation logic from an SCC to a Function.
I wrote the infrastructure to test this but didn't actually use it in
the unit test where it was designed to be used. =[ My bad. Once
I actually added it to the test case I discovered that it also hadn't
been properly implemented, so I've implemented it. The logic in the FAM
proxy for an SCC pass to propagate invalidation follows the same ideas
as the FAM proxy for a Module pass, but the implementation is a bit
different to reflect the fact that it is forwarding just for an SCC.
However, implementing this correctly uncovered a surprising "bug" (it
was conservatively correct but relatively very expensive) in how we
handle invalidation when splitting one SCC into multiple SCCs. We did an
eager invalidation when in reality we should be deferring invaliadtion
for the *current* SCC to the CGSCC pass manager and just invaliating the
newly constructed SCCs. Otherwise we end up invalidating too much too
soon. This was exposed by the inliner test case that I've updated. Now,
we invalidate *just* the split off '(test1_f)' SCC when doing the CG
update, and then the inliner finishes and invalidates the '(test1_g,
test1_h)' SCC's analyses. The first few attempts at fixing this hit
still more bugs, but all of those are covered by existing tests. For
example, the inliner should also preserve the FAM proxy to avoid
unnecesasry invalidation, and this is safe because the CG update
routines it uses handle any necessary adjustments to the FAM proxy.
Finally, the unittests for the CGSCC pass manager needed a bunch of
updates where we weren't correctly preserving the FAM proxy because it
hadn't been fully implemented and failing to preserve it didn't matter.
Note that this doesn't yet fix the current crasher due to MemSSA finding
a stale dominator tree, but without this the fix to that crasher doesn't
really make any sense when testing because it relies on the proxy
behavior.
llvm-svn: 307487
2017-07-09 11:59:31 +08:00
|
|
|
PA.preserve<FunctionAnalysisManagerCGSCCProxy>();
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 14:34:44 +08:00
|
|
|
PA.preserve<FunctionAnalysisManagerModuleProxy>();
|
|
|
|
|
PA.preserve<TestFunctionAnalysis>();
|
|
|
|
|
return PA;
|
|
|
|
|
}));
|
|
|
|
|
|
|
|
|
|
// And now a second CGSCC run which requires the SCC analysis again. This
|
|
|
|
|
// will trigger re-running it.
|
|
|
|
|
FunctionPassManager FPM2(/*DebugLogging*/ true);
|
|
|
|
|
FPM2.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
|
|
|
|
|
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
|
|
|
|
|
CGPM2.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM2)));
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
|
|
|
|
|
|
|
|
|
|
MPM.run(*M, MAM);
|
|
|
|
|
// One run and 6 functions.
|
|
|
|
|
EXPECT_EQ(6, FunctionAnalysisRuns);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Check that if the lazy call graph itself isn't preserved we still manage to
|
|
|
|
|
// invalidate everything.
|
|
|
|
|
TEST_F(CGSCCPassManagerTest,
|
|
|
|
|
TestModulePassInvalidatesFunctionAnalysisNestedInCGSCCOnCGChange) {
|
|
|
|
|
MAM.registerPass([&] { return LazyCallGraphAnalysis(); });
|
|
|
|
|
|
|
|
|
|
int FunctionAnalysisRuns = 0;
|
|
|
|
|
FAM.registerPass([&] { return TestFunctionAnalysis(FunctionAnalysisRuns); });
|
|
|
|
|
|
|
|
|
|
ModulePassManager MPM(/*DebugLogging*/ true);
|
|
|
|
|
|
|
|
|
|
// First force the analysis to be run.
|
|
|
|
|
FunctionPassManager FPM1(/*DebugLogging*/ true);
|
|
|
|
|
FPM1.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
|
|
|
|
|
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
|
|
|
|
|
CGPM1.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM1)));
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
|
|
|
|
|
|
|
|
|
|
// Now run a module pass that preserves the LazyCallGraph but not the
|
|
|
|
|
// Function analysis.
|
|
|
|
|
MPM.addPass(LambdaModulePass([&](Module &M, ModuleAnalysisManager &) {
|
|
|
|
|
PreservedAnalyses PA;
|
|
|
|
|
return PA;
|
|
|
|
|
}));
|
|
|
|
|
|
|
|
|
|
// And now a second CGSCC run which requires the SCC analysis again. This
|
|
|
|
|
// will trigger re-running it.
|
|
|
|
|
FunctionPassManager FPM2(/*DebugLogging*/ true);
|
|
|
|
|
FPM2.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
|
|
|
|
|
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
|
|
|
|
|
CGPM2.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM2)));
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
|
|
|
|
|
|
|
|
|
|
MPM.run(*M, MAM);
|
|
|
|
|
// Two runs and 6 functions.
|
|
|
|
|
EXPECT_EQ(2 * 6, FunctionAnalysisRuns);
|
|
|
|
|
}
|
2016-12-27 16:40:39 +08:00
|
|
|
|
|
|
|
|
/// A test CGSCC-level analysis pass which caches in its result another
|
|
|
|
|
/// analysis pass and uses it to serve queries. This requires the result to
|
|
|
|
|
/// invalidate itself when its dependency is invalidated.
|
|
|
|
|
///
|
|
|
|
|
/// FIXME: Currently this doesn't also depend on a function analysis, and if it
|
|
|
|
|
/// did we would fail to invalidate it correctly.
|
|
|
|
|
struct TestIndirectSCCAnalysis
|
|
|
|
|
: public AnalysisInfoMixin<TestIndirectSCCAnalysis> {
|
|
|
|
|
struct Result {
|
|
|
|
|
Result(TestSCCAnalysis::Result &SCCDep, TestModuleAnalysis::Result &MDep)
|
|
|
|
|
: SCCDep(SCCDep), MDep(MDep) {}
|
|
|
|
|
TestSCCAnalysis::Result &SCCDep;
|
|
|
|
|
TestModuleAnalysis::Result &MDep;
|
|
|
|
|
|
|
|
|
|
bool invalidate(LazyCallGraph::SCC &C, const PreservedAnalyses &PA,
|
|
|
|
|
CGSCCAnalysisManager::Invalidator &Inv) {
|
|
|
|
|
auto PAC = PA.getChecker<TestIndirectSCCAnalysis>();
|
|
|
|
|
return !(PAC.preserved() ||
|
|
|
|
|
PAC.preservedSet<AllAnalysesOn<LazyCallGraph::SCC>>()) ||
|
|
|
|
|
Inv.invalidate<TestSCCAnalysis>(C, PA);
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
TestIndirectSCCAnalysis(int &Runs) : Runs(Runs) {}
|
|
|
|
|
|
|
|
|
|
/// Run the analysis pass over the function and return a result.
|
|
|
|
|
Result run(LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
|
|
|
|
|
LazyCallGraph &CG) {
|
|
|
|
|
++Runs;
|
|
|
|
|
auto &SCCDep = AM.getResult<TestSCCAnalysis>(C, CG);
|
|
|
|
|
|
|
|
|
|
auto &ModuleProxy = AM.getResult<ModuleAnalysisManagerCGSCCProxy>(C, CG);
|
|
|
|
|
const ModuleAnalysisManager &MAM = ModuleProxy.getManager();
|
|
|
|
|
// For the test, we insist that the module analysis starts off in the
|
|
|
|
|
// cache.
|
|
|
|
|
auto &MDep = *MAM.getCachedResult<TestModuleAnalysis>(
|
|
|
|
|
*C.begin()->getFunction().getParent());
|
|
|
|
|
// Register the dependency as module analysis dependencies have to be
|
|
|
|
|
// pre-registered on the proxy.
|
|
|
|
|
ModuleProxy.registerOuterAnalysisInvalidation<TestModuleAnalysis,
|
|
|
|
|
TestIndirectSCCAnalysis>();
|
|
|
|
|
|
|
|
|
|
return Result(SCCDep, MDep);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
friend AnalysisInfoMixin<TestIndirectSCCAnalysis>;
|
|
|
|
|
static AnalysisKey Key;
|
|
|
|
|
|
|
|
|
|
int &Runs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
AnalysisKey TestIndirectSCCAnalysis::Key;
|
|
|
|
|
|
|
|
|
|
/// A test analysis pass which caches in its result the result from the above
|
|
|
|
|
/// indirect analysis pass.
|
|
|
|
|
///
|
|
|
|
|
/// This allows us to ensure that whenever an analysis pass is invalidated due
|
|
|
|
|
/// to dependencies (especially dependencies across IR units that trigger
|
|
|
|
|
/// asynchronous invalidation) we correctly detect that this may in turn cause
|
|
|
|
|
/// other analysis to be invalidated.
|
|
|
|
|
struct TestDoublyIndirectSCCAnalysis
|
|
|
|
|
: public AnalysisInfoMixin<TestDoublyIndirectSCCAnalysis> {
|
|
|
|
|
struct Result {
|
|
|
|
|
Result(TestIndirectSCCAnalysis::Result &IDep) : IDep(IDep) {}
|
|
|
|
|
TestIndirectSCCAnalysis::Result &IDep;
|
|
|
|
|
|
|
|
|
|
bool invalidate(LazyCallGraph::SCC &C, const PreservedAnalyses &PA,
|
|
|
|
|
CGSCCAnalysisManager::Invalidator &Inv) {
|
|
|
|
|
auto PAC = PA.getChecker<TestDoublyIndirectSCCAnalysis>();
|
|
|
|
|
return !(PAC.preserved() ||
|
|
|
|
|
PAC.preservedSet<AllAnalysesOn<LazyCallGraph::SCC>>()) ||
|
|
|
|
|
Inv.invalidate<TestIndirectSCCAnalysis>(C, PA);
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
TestDoublyIndirectSCCAnalysis(int &Runs) : Runs(Runs) {}
|
|
|
|
|
|
|
|
|
|
/// Run the analysis pass over the function and return a result.
|
|
|
|
|
Result run(LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
|
|
|
|
|
LazyCallGraph &CG) {
|
|
|
|
|
++Runs;
|
|
|
|
|
auto &IDep = AM.getResult<TestIndirectSCCAnalysis>(C, CG);
|
|
|
|
|
return Result(IDep);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
friend AnalysisInfoMixin<TestDoublyIndirectSCCAnalysis>;
|
|
|
|
|
static AnalysisKey Key;
|
|
|
|
|
|
|
|
|
|
int &Runs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
AnalysisKey TestDoublyIndirectSCCAnalysis::Key;
|
|
|
|
|
|
|
|
|
|
/// A test analysis pass which caches results from three different IR unit
|
|
|
|
|
/// layers and requires intermediate layers to correctly propagate the entire
|
|
|
|
|
/// distance.
|
|
|
|
|
struct TestIndirectFunctionAnalysis
|
|
|
|
|
: public AnalysisInfoMixin<TestIndirectFunctionAnalysis> {
|
|
|
|
|
struct Result {
|
|
|
|
|
Result(TestFunctionAnalysis::Result &FDep, TestModuleAnalysis::Result &MDep,
|
|
|
|
|
TestSCCAnalysis::Result &SCCDep)
|
|
|
|
|
: FDep(FDep), MDep(MDep), SCCDep(SCCDep) {}
|
|
|
|
|
TestFunctionAnalysis::Result &FDep;
|
|
|
|
|
TestModuleAnalysis::Result &MDep;
|
|
|
|
|
TestSCCAnalysis::Result &SCCDep;
|
|
|
|
|
|
|
|
|
|
bool invalidate(Function &F, const PreservedAnalyses &PA,
|
|
|
|
|
FunctionAnalysisManager::Invalidator &Inv) {
|
|
|
|
|
auto PAC = PA.getChecker<TestIndirectFunctionAnalysis>();
|
|
|
|
|
return !(PAC.preserved() ||
|
|
|
|
|
PAC.preservedSet<AllAnalysesOn<Function>>()) ||
|
|
|
|
|
Inv.invalidate<TestFunctionAnalysis>(F, PA);
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
TestIndirectFunctionAnalysis(int &Runs) : Runs(Runs) {}
|
|
|
|
|
|
|
|
|
|
/// Run the analysis pass over the function and return a result.
|
|
|
|
|
Result run(Function &F, FunctionAnalysisManager &AM) {
|
|
|
|
|
++Runs;
|
|
|
|
|
auto &FDep = AM.getResult<TestFunctionAnalysis>(F);
|
|
|
|
|
|
|
|
|
|
auto &ModuleProxy = AM.getResult<ModuleAnalysisManagerFunctionProxy>(F);
|
|
|
|
|
const ModuleAnalysisManager &MAM = ModuleProxy.getManager();
|
|
|
|
|
// For the test, we insist that the module analysis starts off in the
|
|
|
|
|
// cache.
|
|
|
|
|
auto &MDep = *MAM.getCachedResult<TestModuleAnalysis>(*F.getParent());
|
|
|
|
|
// Register the dependency as module analysis dependencies have to be
|
|
|
|
|
// pre-registered on the proxy.
|
|
|
|
|
ModuleProxy.registerOuterAnalysisInvalidation<
|
|
|
|
|
TestModuleAnalysis, TestIndirectFunctionAnalysis>();
|
|
|
|
|
|
|
|
|
|
// For thet test we assume this is run inside a CGSCC pass manager.
|
|
|
|
|
const LazyCallGraph &CG =
|
|
|
|
|
*MAM.getCachedResult<LazyCallGraphAnalysis>(*F.getParent());
|
|
|
|
|
auto &CGSCCProxy = AM.getResult<CGSCCAnalysisManagerFunctionProxy>(F);
|
|
|
|
|
const CGSCCAnalysisManager &CGAM = CGSCCProxy.getManager();
|
|
|
|
|
// For the test, we insist that the CGSCC analysis starts off in the cache.
|
|
|
|
|
auto &SCCDep =
|
|
|
|
|
*CGAM.getCachedResult<TestSCCAnalysis>(*CG.lookupSCC(*CG.lookup(F)));
|
|
|
|
|
// Register the dependency as CGSCC analysis dependencies have to be
|
|
|
|
|
// pre-registered on the proxy.
|
|
|
|
|
CGSCCProxy.registerOuterAnalysisInvalidation<
|
|
|
|
|
TestSCCAnalysis, TestIndirectFunctionAnalysis>();
|
|
|
|
|
|
|
|
|
|
return Result(FDep, MDep, SCCDep);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
friend AnalysisInfoMixin<TestIndirectFunctionAnalysis>;
|
|
|
|
|
static AnalysisKey Key;
|
|
|
|
|
|
|
|
|
|
int &Runs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
AnalysisKey TestIndirectFunctionAnalysis::Key;
|
|
|
|
|
|
|
|
|
|
TEST_F(CGSCCPassManagerTest, TestIndirectAnalysisInvalidation) {
|
|
|
|
|
int ModuleAnalysisRuns = 0;
|
|
|
|
|
MAM.registerPass([&] { return TestModuleAnalysis(ModuleAnalysisRuns); });
|
|
|
|
|
|
|
|
|
|
int SCCAnalysisRuns = 0, IndirectSCCAnalysisRuns = 0,
|
|
|
|
|
DoublyIndirectSCCAnalysisRuns = 0;
|
|
|
|
|
CGAM.registerPass([&] { return TestSCCAnalysis(SCCAnalysisRuns); });
|
|
|
|
|
CGAM.registerPass(
|
|
|
|
|
[&] { return TestIndirectSCCAnalysis(IndirectSCCAnalysisRuns); });
|
|
|
|
|
CGAM.registerPass([&] {
|
|
|
|
|
return TestDoublyIndirectSCCAnalysis(DoublyIndirectSCCAnalysisRuns);
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
int FunctionAnalysisRuns = 0, IndirectFunctionAnalysisRuns = 0;
|
|
|
|
|
FAM.registerPass([&] { return TestFunctionAnalysis(FunctionAnalysisRuns); });
|
|
|
|
|
FAM.registerPass([&] {
|
|
|
|
|
return TestIndirectFunctionAnalysis(IndirectFunctionAnalysisRuns);
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
ModulePassManager MPM(/*DebugLogging*/ true);
|
|
|
|
|
|
|
|
|
|
int FunctionCount = 0;
|
|
|
|
|
CGSCCPassManager CGPM(/*DebugLogging*/ true);
|
|
|
|
|
// First just use the analysis to get the function count and preserve
|
|
|
|
|
// everything.
|
|
|
|
|
CGPM.addPass(
|
|
|
|
|
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
|
|
|
|
|
LazyCallGraph &CG, CGSCCUpdateResult &) {
|
|
|
|
|
auto &DoublyIndirectResult =
|
|
|
|
|
AM.getResult<TestDoublyIndirectSCCAnalysis>(C, CG);
|
|
|
|
|
auto &IndirectResult = DoublyIndirectResult.IDep;
|
|
|
|
|
FunctionCount += IndirectResult.SCCDep.FunctionCount;
|
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
|
}));
|
[PM] Finish implementing and fix a chain of bugs uncovered by testing
the invalidation propagation logic from an SCC to a Function.
I wrote the infrastructure to test this but didn't actually use it in
the unit test where it was designed to be used. =[ My bad. Once
I actually added it to the test case I discovered that it also hadn't
been properly implemented, so I've implemented it. The logic in the FAM
proxy for an SCC pass to propagate invalidation follows the same ideas
as the FAM proxy for a Module pass, but the implementation is a bit
different to reflect the fact that it is forwarding just for an SCC.
However, implementing this correctly uncovered a surprising "bug" (it
was conservatively correct but relatively very expensive) in how we
handle invalidation when splitting one SCC into multiple SCCs. We did an
eager invalidation when in reality we should be deferring invaliadtion
for the *current* SCC to the CGSCC pass manager and just invaliating the
newly constructed SCCs. Otherwise we end up invalidating too much too
soon. This was exposed by the inliner test case that I've updated. Now,
we invalidate *just* the split off '(test1_f)' SCC when doing the CG
update, and then the inliner finishes and invalidates the '(test1_g,
test1_h)' SCC's analyses. The first few attempts at fixing this hit
still more bugs, but all of those are covered by existing tests. For
example, the inliner should also preserve the FAM proxy to avoid
unnecesasry invalidation, and this is safe because the CG update
routines it uses handle any necessary adjustments to the FAM proxy.
Finally, the unittests for the CGSCC pass manager needed a bunch of
updates where we weren't correctly preserving the FAM proxy because it
hadn't been fully implemented and failing to preserve it didn't matter.
Note that this doesn't yet fix the current crasher due to MemSSA finding
a stale dominator tree, but without this the fix to that crasher doesn't
really make any sense when testing because it relies on the proxy
behavior.
llvm-svn: 307487
2017-07-09 11:59:31 +08:00
|
|
|
CGPM.addPass(createCGSCCToFunctionPassAdaptor(
|
|
|
|
|
RequireAnalysisPass<TestIndirectFunctionAnalysis, Function>()));
|
|
|
|
|
|
2016-12-27 16:40:39 +08:00
|
|
|
// Next, invalidate
|
|
|
|
|
// - both analyses for the (f) and (x) SCCs,
|
|
|
|
|
// - just the underlying (indirect) analysis for (g) SCC, and
|
|
|
|
|
// - just the direct analysis for (h1,h2,h3) SCC.
|
|
|
|
|
CGPM.addPass(
|
|
|
|
|
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
|
|
|
|
|
LazyCallGraph &CG, CGSCCUpdateResult &) {
|
|
|
|
|
auto &DoublyIndirectResult =
|
|
|
|
|
AM.getResult<TestDoublyIndirectSCCAnalysis>(C, CG);
|
|
|
|
|
auto &IndirectResult = DoublyIndirectResult.IDep;
|
|
|
|
|
FunctionCount += IndirectResult.SCCDep.FunctionCount;
|
|
|
|
|
auto PA = PreservedAnalyses::none();
|
[PM] Finish implementing and fix a chain of bugs uncovered by testing
the invalidation propagation logic from an SCC to a Function.
I wrote the infrastructure to test this but didn't actually use it in
the unit test where it was designed to be used. =[ My bad. Once
I actually added it to the test case I discovered that it also hadn't
been properly implemented, so I've implemented it. The logic in the FAM
proxy for an SCC pass to propagate invalidation follows the same ideas
as the FAM proxy for a Module pass, but the implementation is a bit
different to reflect the fact that it is forwarding just for an SCC.
However, implementing this correctly uncovered a surprising "bug" (it
was conservatively correct but relatively very expensive) in how we
handle invalidation when splitting one SCC into multiple SCCs. We did an
eager invalidation when in reality we should be deferring invaliadtion
for the *current* SCC to the CGSCC pass manager and just invaliating the
newly constructed SCCs. Otherwise we end up invalidating too much too
soon. This was exposed by the inliner test case that I've updated. Now,
we invalidate *just* the split off '(test1_f)' SCC when doing the CG
update, and then the inliner finishes and invalidates the '(test1_g,
test1_h)' SCC's analyses. The first few attempts at fixing this hit
still more bugs, but all of those are covered by existing tests. For
example, the inliner should also preserve the FAM proxy to avoid
unnecesasry invalidation, and this is safe because the CG update
routines it uses handle any necessary adjustments to the FAM proxy.
Finally, the unittests for the CGSCC pass manager needed a bunch of
updates where we weren't correctly preserving the FAM proxy because it
hadn't been fully implemented and failing to preserve it didn't matter.
Note that this doesn't yet fix the current crasher due to MemSSA finding
a stale dominator tree, but without this the fix to that crasher doesn't
really make any sense when testing because it relies on the proxy
behavior.
llvm-svn: 307487
2017-07-09 11:59:31 +08:00
|
|
|
PA.preserve<FunctionAnalysisManagerCGSCCProxy>();
|
|
|
|
|
PA.preserveSet<AllAnalysesOn<Function>>();
|
2016-12-27 16:40:39 +08:00
|
|
|
if (C.getName() == "(g)")
|
|
|
|
|
PA.preserve<TestSCCAnalysis>();
|
|
|
|
|
else if (C.getName() == "(h3, h1, h2)")
|
|
|
|
|
PA.preserve<TestIndirectSCCAnalysis>();
|
|
|
|
|
return PA;
|
|
|
|
|
}));
|
[PM] Finish implementing and fix a chain of bugs uncovered by testing
the invalidation propagation logic from an SCC to a Function.
I wrote the infrastructure to test this but didn't actually use it in
the unit test where it was designed to be used. =[ My bad. Once
I actually added it to the test case I discovered that it also hadn't
been properly implemented, so I've implemented it. The logic in the FAM
proxy for an SCC pass to propagate invalidation follows the same ideas
as the FAM proxy for a Module pass, but the implementation is a bit
different to reflect the fact that it is forwarding just for an SCC.
However, implementing this correctly uncovered a surprising "bug" (it
was conservatively correct but relatively very expensive) in how we
handle invalidation when splitting one SCC into multiple SCCs. We did an
eager invalidation when in reality we should be deferring invaliadtion
for the *current* SCC to the CGSCC pass manager and just invaliating the
newly constructed SCCs. Otherwise we end up invalidating too much too
soon. This was exposed by the inliner test case that I've updated. Now,
we invalidate *just* the split off '(test1_f)' SCC when doing the CG
update, and then the inliner finishes and invalidates the '(test1_g,
test1_h)' SCC's analyses. The first few attempts at fixing this hit
still more bugs, but all of those are covered by existing tests. For
example, the inliner should also preserve the FAM proxy to avoid
unnecesasry invalidation, and this is safe because the CG update
routines it uses handle any necessary adjustments to the FAM proxy.
Finally, the unittests for the CGSCC pass manager needed a bunch of
updates where we weren't correctly preserving the FAM proxy because it
hadn't been fully implemented and failing to preserve it didn't matter.
Note that this doesn't yet fix the current crasher due to MemSSA finding
a stale dominator tree, but without this the fix to that crasher doesn't
really make any sense when testing because it relies on the proxy
behavior.
llvm-svn: 307487
2017-07-09 11:59:31 +08:00
|
|
|
// Finally, use the analysis again on each SCC (and function), forcing
|
|
|
|
|
// re-computation for all of them.
|
2016-12-27 16:40:39 +08:00
|
|
|
CGPM.addPass(
|
|
|
|
|
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
|
|
|
|
|
LazyCallGraph &CG, CGSCCUpdateResult &) {
|
|
|
|
|
auto &DoublyIndirectResult =
|
|
|
|
|
AM.getResult<TestDoublyIndirectSCCAnalysis>(C, CG);
|
|
|
|
|
auto &IndirectResult = DoublyIndirectResult.IDep;
|
|
|
|
|
FunctionCount += IndirectResult.SCCDep.FunctionCount;
|
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
|
}));
|
[PM] Finish implementing and fix a chain of bugs uncovered by testing
the invalidation propagation logic from an SCC to a Function.
I wrote the infrastructure to test this but didn't actually use it in
the unit test where it was designed to be used. =[ My bad. Once
I actually added it to the test case I discovered that it also hadn't
been properly implemented, so I've implemented it. The logic in the FAM
proxy for an SCC pass to propagate invalidation follows the same ideas
as the FAM proxy for a Module pass, but the implementation is a bit
different to reflect the fact that it is forwarding just for an SCC.
However, implementing this correctly uncovered a surprising "bug" (it
was conservatively correct but relatively very expensive) in how we
handle invalidation when splitting one SCC into multiple SCCs. We did an
eager invalidation when in reality we should be deferring invaliadtion
for the *current* SCC to the CGSCC pass manager and just invaliating the
newly constructed SCCs. Otherwise we end up invalidating too much too
soon. This was exposed by the inliner test case that I've updated. Now,
we invalidate *just* the split off '(test1_f)' SCC when doing the CG
update, and then the inliner finishes and invalidates the '(test1_g,
test1_h)' SCC's analyses. The first few attempts at fixing this hit
still more bugs, but all of those are covered by existing tests. For
example, the inliner should also preserve the FAM proxy to avoid
unnecesasry invalidation, and this is safe because the CG update
routines it uses handle any necessary adjustments to the FAM proxy.
Finally, the unittests for the CGSCC pass manager needed a bunch of
updates where we weren't correctly preserving the FAM proxy because it
hadn't been fully implemented and failing to preserve it didn't matter.
Note that this doesn't yet fix the current crasher due to MemSSA finding
a stale dominator tree, but without this the fix to that crasher doesn't
really make any sense when testing because it relies on the proxy
behavior.
llvm-svn: 307487
2017-07-09 11:59:31 +08:00
|
|
|
CGPM.addPass(createCGSCCToFunctionPassAdaptor(
|
|
|
|
|
RequireAnalysisPass<TestIndirectFunctionAnalysis, Function>()));
|
2016-12-27 16:40:39 +08:00
|
|
|
|
|
|
|
|
// Create a second CGSCC pass manager. This will cause the module-level
|
|
|
|
|
// invalidation to occur, which will force yet another invalidation of the
|
|
|
|
|
// indirect SCC-level analysis as the module analysis it depends on gets
|
|
|
|
|
// invalidated.
|
|
|
|
|
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
|
|
|
|
|
CGPM2.addPass(
|
|
|
|
|
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
|
|
|
|
|
LazyCallGraph &CG, CGSCCUpdateResult &) {
|
|
|
|
|
auto &DoublyIndirectResult =
|
|
|
|
|
AM.getResult<TestDoublyIndirectSCCAnalysis>(C, CG);
|
|
|
|
|
auto &IndirectResult = DoublyIndirectResult.IDep;
|
|
|
|
|
FunctionCount += IndirectResult.SCCDep.FunctionCount;
|
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
|
}));
|
[PM] Finish implementing and fix a chain of bugs uncovered by testing
the invalidation propagation logic from an SCC to a Function.
I wrote the infrastructure to test this but didn't actually use it in
the unit test where it was designed to be used. =[ My bad. Once
I actually added it to the test case I discovered that it also hadn't
been properly implemented, so I've implemented it. The logic in the FAM
proxy for an SCC pass to propagate invalidation follows the same ideas
as the FAM proxy for a Module pass, but the implementation is a bit
different to reflect the fact that it is forwarding just for an SCC.
However, implementing this correctly uncovered a surprising "bug" (it
was conservatively correct but relatively very expensive) in how we
handle invalidation when splitting one SCC into multiple SCCs. We did an
eager invalidation when in reality we should be deferring invaliadtion
for the *current* SCC to the CGSCC pass manager and just invaliating the
newly constructed SCCs. Otherwise we end up invalidating too much too
soon. This was exposed by the inliner test case that I've updated. Now,
we invalidate *just* the split off '(test1_f)' SCC when doing the CG
update, and then the inliner finishes and invalidates the '(test1_g,
test1_h)' SCC's analyses. The first few attempts at fixing this hit
still more bugs, but all of those are covered by existing tests. For
example, the inliner should also preserve the FAM proxy to avoid
unnecesasry invalidation, and this is safe because the CG update
routines it uses handle any necessary adjustments to the FAM proxy.
Finally, the unittests for the CGSCC pass manager needed a bunch of
updates where we weren't correctly preserving the FAM proxy because it
hadn't been fully implemented and failing to preserve it didn't matter.
Note that this doesn't yet fix the current crasher due to MemSSA finding
a stale dominator tree, but without this the fix to that crasher doesn't
really make any sense when testing because it relies on the proxy
behavior.
llvm-svn: 307487
2017-07-09 11:59:31 +08:00
|
|
|
CGPM2.addPass(createCGSCCToFunctionPassAdaptor(
|
|
|
|
|
RequireAnalysisPass<TestIndirectFunctionAnalysis, Function>()));
|
2016-12-27 16:40:39 +08:00
|
|
|
|
[PM] Finish implementing and fix a chain of bugs uncovered by testing
the invalidation propagation logic from an SCC to a Function.
I wrote the infrastructure to test this but didn't actually use it in
the unit test where it was designed to be used. =[ My bad. Once
I actually added it to the test case I discovered that it also hadn't
been properly implemented, so I've implemented it. The logic in the FAM
proxy for an SCC pass to propagate invalidation follows the same ideas
as the FAM proxy for a Module pass, but the implementation is a bit
different to reflect the fact that it is forwarding just for an SCC.
However, implementing this correctly uncovered a surprising "bug" (it
was conservatively correct but relatively very expensive) in how we
handle invalidation when splitting one SCC into multiple SCCs. We did an
eager invalidation when in reality we should be deferring invaliadtion
for the *current* SCC to the CGSCC pass manager and just invaliating the
newly constructed SCCs. Otherwise we end up invalidating too much too
soon. This was exposed by the inliner test case that I've updated. Now,
we invalidate *just* the split off '(test1_f)' SCC when doing the CG
update, and then the inliner finishes and invalidates the '(test1_g,
test1_h)' SCC's analyses. The first few attempts at fixing this hit
still more bugs, but all of those are covered by existing tests. For
example, the inliner should also preserve the FAM proxy to avoid
unnecesasry invalidation, and this is safe because the CG update
routines it uses handle any necessary adjustments to the FAM proxy.
Finally, the unittests for the CGSCC pass manager needed a bunch of
updates where we weren't correctly preserving the FAM proxy because it
hadn't been fully implemented and failing to preserve it didn't matter.
Note that this doesn't yet fix the current crasher due to MemSSA finding
a stale dominator tree, but without this the fix to that crasher doesn't
really make any sense when testing because it relies on the proxy
behavior.
llvm-svn: 307487
2017-07-09 11:59:31 +08:00
|
|
|
// Add a requires pass to populate the module analysis and then our CGSCC
|
2016-12-27 16:40:39 +08:00
|
|
|
// pass pipeline.
|
|
|
|
|
MPM.addPass(RequireAnalysisPass<TestModuleAnalysis, Module>());
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM)));
|
|
|
|
|
// Now require the module analysis again (it will have been invalidated once)
|
[PM] Finish implementing and fix a chain of bugs uncovered by testing
the invalidation propagation logic from an SCC to a Function.
I wrote the infrastructure to test this but didn't actually use it in
the unit test where it was designed to be used. =[ My bad. Once
I actually added it to the test case I discovered that it also hadn't
been properly implemented, so I've implemented it. The logic in the FAM
proxy for an SCC pass to propagate invalidation follows the same ideas
as the FAM proxy for a Module pass, but the implementation is a bit
different to reflect the fact that it is forwarding just for an SCC.
However, implementing this correctly uncovered a surprising "bug" (it
was conservatively correct but relatively very expensive) in how we
handle invalidation when splitting one SCC into multiple SCCs. We did an
eager invalidation when in reality we should be deferring invaliadtion
for the *current* SCC to the CGSCC pass manager and just invaliating the
newly constructed SCCs. Otherwise we end up invalidating too much too
soon. This was exposed by the inliner test case that I've updated. Now,
we invalidate *just* the split off '(test1_f)' SCC when doing the CG
update, and then the inliner finishes and invalidates the '(test1_g,
test1_h)' SCC's analyses. The first few attempts at fixing this hit
still more bugs, but all of those are covered by existing tests. For
example, the inliner should also preserve the FAM proxy to avoid
unnecesasry invalidation, and this is safe because the CG update
routines it uses handle any necessary adjustments to the FAM proxy.
Finally, the unittests for the CGSCC pass manager needed a bunch of
updates where we weren't correctly preserving the FAM proxy because it
hadn't been fully implemented and failing to preserve it didn't matter.
Note that this doesn't yet fix the current crasher due to MemSSA finding
a stale dominator tree, but without this the fix to that crasher doesn't
really make any sense when testing because it relies on the proxy
behavior.
llvm-svn: 307487
2017-07-09 11:59:31 +08:00
|
|
|
// and then use it again from our second CGSCC pipeline..
|
2016-12-27 16:40:39 +08:00
|
|
|
MPM.addPass(RequireAnalysisPass<TestModuleAnalysis, Module>());
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
|
|
|
|
|
MPM.run(*M, MAM);
|
|
|
|
|
|
|
|
|
|
// There are generally two possible runs for each of the four SCCs. But
|
|
|
|
|
// for one SCC, we only invalidate the indirect analysis so the base one
|
|
|
|
|
// only gets run seven times.
|
|
|
|
|
EXPECT_EQ(7, SCCAnalysisRuns);
|
|
|
|
|
// The module analysis pass should be run twice here.
|
|
|
|
|
EXPECT_EQ(2, ModuleAnalysisRuns);
|
|
|
|
|
// The indirect analysis is invalidated (either directly or indirectly) three
|
|
|
|
|
// times for each of four SCCs.
|
|
|
|
|
EXPECT_EQ(3 * 4, IndirectSCCAnalysisRuns);
|
|
|
|
|
EXPECT_EQ(3 * 4, DoublyIndirectSCCAnalysisRuns);
|
|
|
|
|
|
[PM] Finish implementing and fix a chain of bugs uncovered by testing
the invalidation propagation logic from an SCC to a Function.
I wrote the infrastructure to test this but didn't actually use it in
the unit test where it was designed to be used. =[ My bad. Once
I actually added it to the test case I discovered that it also hadn't
been properly implemented, so I've implemented it. The logic in the FAM
proxy for an SCC pass to propagate invalidation follows the same ideas
as the FAM proxy for a Module pass, but the implementation is a bit
different to reflect the fact that it is forwarding just for an SCC.
However, implementing this correctly uncovered a surprising "bug" (it
was conservatively correct but relatively very expensive) in how we
handle invalidation when splitting one SCC into multiple SCCs. We did an
eager invalidation when in reality we should be deferring invaliadtion
for the *current* SCC to the CGSCC pass manager and just invaliating the
newly constructed SCCs. Otherwise we end up invalidating too much too
soon. This was exposed by the inliner test case that I've updated. Now,
we invalidate *just* the split off '(test1_f)' SCC when doing the CG
update, and then the inliner finishes and invalidates the '(test1_g,
test1_h)' SCC's analyses. The first few attempts at fixing this hit
still more bugs, but all of those are covered by existing tests. For
example, the inliner should also preserve the FAM proxy to avoid
unnecesasry invalidation, and this is safe because the CG update
routines it uses handle any necessary adjustments to the FAM proxy.
Finally, the unittests for the CGSCC pass manager needed a bunch of
updates where we weren't correctly preserving the FAM proxy because it
hadn't been fully implemented and failing to preserve it didn't matter.
Note that this doesn't yet fix the current crasher due to MemSSA finding
a stale dominator tree, but without this the fix to that crasher doesn't
really make any sense when testing because it relies on the proxy
behavior.
llvm-svn: 307487
2017-07-09 11:59:31 +08:00
|
|
|
// We run the indirect function analysis once per function the first time.
|
|
|
|
|
// Then we re-run it for every SCC but "(g)". Then we re-run it for every
|
|
|
|
|
// function again.
|
|
|
|
|
EXPECT_EQ(6 + 5 + 6, IndirectFunctionAnalysisRuns);
|
|
|
|
|
|
2016-12-27 16:40:39 +08:00
|
|
|
// Four passes count each of six functions once (via SCCs).
|
|
|
|
|
EXPECT_EQ(4 * 6, FunctionCount);
|
|
|
|
|
}
|
2017-07-09 21:16:55 +08:00
|
|
|
|
|
|
|
|
TEST_F(CGSCCPassManagerTest, TestAnalysisInvalidationCGSCCUpdate) {
|
|
|
|
|
int ModuleAnalysisRuns = 0;
|
|
|
|
|
MAM.registerPass([&] { return TestModuleAnalysis(ModuleAnalysisRuns); });
|
|
|
|
|
|
|
|
|
|
int SCCAnalysisRuns = 0, IndirectSCCAnalysisRuns = 0,
|
|
|
|
|
DoublyIndirectSCCAnalysisRuns = 0;
|
|
|
|
|
CGAM.registerPass([&] { return TestSCCAnalysis(SCCAnalysisRuns); });
|
|
|
|
|
CGAM.registerPass(
|
|
|
|
|
[&] { return TestIndirectSCCAnalysis(IndirectSCCAnalysisRuns); });
|
|
|
|
|
CGAM.registerPass([&] {
|
|
|
|
|
return TestDoublyIndirectSCCAnalysis(DoublyIndirectSCCAnalysisRuns);
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
int FunctionAnalysisRuns = 0, IndirectFunctionAnalysisRuns = 0;
|
|
|
|
|
FAM.registerPass([&] { return TestFunctionAnalysis(FunctionAnalysisRuns); });
|
|
|
|
|
FAM.registerPass([&] {
|
|
|
|
|
return TestIndirectFunctionAnalysis(IndirectFunctionAnalysisRuns);
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
ModulePassManager MPM(/*DebugLogging*/ true);
|
|
|
|
|
|
|
|
|
|
CGSCCPassManager CGPM(/*DebugLogging*/ true);
|
|
|
|
|
// First just use the analysis to get the function count and preserve
|
|
|
|
|
// everything.
|
|
|
|
|
using RequireTestIndirectFunctionAnalysisPass =
|
|
|
|
|
RequireAnalysisPass<TestIndirectFunctionAnalysis, Function>;
|
|
|
|
|
using RequireTestDoublyIndirectSCCAnalysisPass =
|
|
|
|
|
RequireAnalysisPass<TestDoublyIndirectSCCAnalysis, LazyCallGraph::SCC,
|
|
|
|
|
CGSCCAnalysisManager, LazyCallGraph &,
|
|
|
|
|
CGSCCUpdateResult &>;
|
|
|
|
|
CGPM.addPass(RequireTestDoublyIndirectSCCAnalysisPass());
|
|
|
|
|
CGPM.addPass(createCGSCCToFunctionPassAdaptor(
|
|
|
|
|
RequireTestIndirectFunctionAnalysisPass()));
|
|
|
|
|
|
|
|
|
|
// Next, we inject an SCC pass that invalidates everything for the `(h3, h1,
|
|
|
|
|
// h2)` SCC but also deletes the call edge from `h2` to `h3` and updates the
|
|
|
|
|
// CG. This should successfully invalidate (and force to be re-run) all the
|
|
|
|
|
// analyses for that SCC and for the functions.
|
|
|
|
|
CGPM.addPass(
|
|
|
|
|
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
|
|
|
|
|
LazyCallGraph &CG, CGSCCUpdateResult &UR) {
|
|
|
|
|
(void)AM.getResult<TestDoublyIndirectSCCAnalysis>(C, CG);
|
|
|
|
|
if (C.getName() != "(h3, h1, h2)")
|
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
|
|
|
|
|
|
// Build the preserved set.
|
|
|
|
|
auto PA = PreservedAnalyses::none();
|
|
|
|
|
PA.preserve<FunctionAnalysisManagerCGSCCProxy>();
|
|
|
|
|
PA.preserve<TestIndirectSCCAnalysis>();
|
|
|
|
|
PA.preserve<TestDoublyIndirectSCCAnalysis>();
|
|
|
|
|
|
|
|
|
|
// Delete the call from `h2` to `h3`.
|
|
|
|
|
auto &H2N = *llvm::find_if(
|
|
|
|
|
C, [](LazyCallGraph::Node &N) { return N.getName() == "h2"; });
|
|
|
|
|
auto &H2F = H2N.getFunction();
|
|
|
|
|
auto &H3F = *cast<CallInst>(H2F.begin()->begin())->getCalledFunction();
|
|
|
|
|
assert(H3F.getName() == "h3" && "Wrong called function!");
|
|
|
|
|
H2F.begin()->begin()->eraseFromParent();
|
|
|
|
|
// Insert a bitcast of `h3` so that we retain a ref edge to it.
|
|
|
|
|
(void)CastInst::CreatePointerCast(&H3F,
|
|
|
|
|
Type::getInt8PtrTy(H2F.getContext()),
|
|
|
|
|
"dummy", &*H2F.begin()->begin());
|
|
|
|
|
|
|
|
|
|
// Now update the call graph.
|
|
|
|
|
auto &NewC = updateCGAndAnalysisManagerForFunctionPass(
|
|
|
|
|
CG, C, H2N, AM, UR, /*DebugLogging*/ true);
|
|
|
|
|
assert(&NewC != &C && "Should get a new SCC due to update!");
|
|
|
|
|
|
|
|
|
|
return PA;
|
|
|
|
|
}));
|
|
|
|
|
// Now use the analysis again on each SCC and function, forcing
|
|
|
|
|
// re-computation for all of them.
|
|
|
|
|
CGPM.addPass(RequireTestDoublyIndirectSCCAnalysisPass());
|
|
|
|
|
CGPM.addPass(createCGSCCToFunctionPassAdaptor(
|
|
|
|
|
RequireTestIndirectFunctionAnalysisPass()));
|
|
|
|
|
|
|
|
|
|
// Create another CGSCC pipeline that requires all the analyses again.
|
|
|
|
|
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
|
|
|
|
|
CGPM2.addPass(RequireTestDoublyIndirectSCCAnalysisPass());
|
|
|
|
|
CGPM2.addPass(createCGSCCToFunctionPassAdaptor(
|
|
|
|
|
RequireTestIndirectFunctionAnalysisPass()));
|
|
|
|
|
|
|
|
|
|
// Next we inject an SCC pass that finds the `(h2)` SCC, adds a call to `h3`
|
|
|
|
|
// back to `h2`, and then invalidates everything for what will then be the
|
|
|
|
|
// `(h3, h1, h2)` SCC again.
|
|
|
|
|
CGSCCPassManager CGPM3(/*DebugLogging*/ true);
|
|
|
|
|
CGPM3.addPass(
|
|
|
|
|
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
|
|
|
|
|
LazyCallGraph &CG, CGSCCUpdateResult &UR) {
|
|
|
|
|
(void)AM.getResult<TestDoublyIndirectSCCAnalysis>(C, CG);
|
|
|
|
|
if (C.getName() != "(h2)")
|
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
|
|
|
|
|
|
// Build the preserved set.
|
|
|
|
|
auto PA = PreservedAnalyses::none();
|
|
|
|
|
PA.preserve<FunctionAnalysisManagerCGSCCProxy>();
|
|
|
|
|
PA.preserve<TestIndirectSCCAnalysis>();
|
|
|
|
|
PA.preserve<TestDoublyIndirectSCCAnalysis>();
|
|
|
|
|
|
|
|
|
|
// Delete the bitcast of `h3` that we added earlier.
|
|
|
|
|
auto &H2N = *C.begin();
|
|
|
|
|
auto &H2F = H2N.getFunction();
|
|
|
|
|
auto &H3F = *cast<Function>(cast<BitCastInst>(H2F.begin()->begin())->getOperand(0));
|
|
|
|
|
assert(H3F.getName() == "h3" && "Wrong called function!");
|
|
|
|
|
H2F.begin()->begin()->eraseFromParent();
|
|
|
|
|
// And insert a call to `h3`.
|
|
|
|
|
(void)CallInst::Create(&H3F, {}, "", &*H2F.begin()->begin());
|
|
|
|
|
|
|
|
|
|
// Now update the call graph.
|
|
|
|
|
auto &NewC = updateCGAndAnalysisManagerForFunctionPass(
|
|
|
|
|
CG, C, H2N, AM, UR, /*DebugLogging*/ true);
|
|
|
|
|
assert(&NewC != &C && "Should get a new SCC due to update!");
|
|
|
|
|
|
|
|
|
|
return PA;
|
|
|
|
|
}));
|
|
|
|
|
// Now use the analysis again on each SCC and function, forcing
|
|
|
|
|
// re-computation for all of them.
|
|
|
|
|
CGPM3.addPass(RequireTestDoublyIndirectSCCAnalysisPass());
|
|
|
|
|
CGPM3.addPass(createCGSCCToFunctionPassAdaptor(
|
|
|
|
|
RequireTestIndirectFunctionAnalysisPass()));
|
|
|
|
|
|
|
|
|
|
// Create a second CGSCC pass manager. This will cause the module-level
|
|
|
|
|
// invalidation to occur, which will force yet another invalidation of the
|
|
|
|
|
// indirect SCC-level analysis as the module analysis it depends on gets
|
|
|
|
|
// invalidated.
|
|
|
|
|
CGSCCPassManager CGPM4(/*DebugLogging*/ true);
|
|
|
|
|
CGPM4.addPass(RequireTestDoublyIndirectSCCAnalysisPass());
|
|
|
|
|
CGPM4.addPass(createCGSCCToFunctionPassAdaptor(
|
|
|
|
|
RequireTestIndirectFunctionAnalysisPass()));
|
|
|
|
|
|
|
|
|
|
// Add a requires pass to populate the module analysis and then one of our
|
|
|
|
|
// CGSCC pipelines. Repeat for all four CGSCC pipelines.
|
|
|
|
|
MPM.addPass(RequireAnalysisPass<TestModuleAnalysis, Module>());
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM)));
|
|
|
|
|
MPM.addPass(RequireAnalysisPass<TestModuleAnalysis, Module>());
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
|
|
|
|
|
MPM.addPass(RequireAnalysisPass<TestModuleAnalysis, Module>());
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM3)));
|
|
|
|
|
MPM.addPass(RequireAnalysisPass<TestModuleAnalysis, Module>());
|
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM4)));
|
|
|
|
|
MPM.run(*M, MAM);
|
|
|
|
|
|
|
|
|
|
// We run over four SCCs the first time. But then we split an SCC into three.
|
|
|
|
|
// And then we merge those three back into one.
|
|
|
|
|
EXPECT_EQ(4 + 3 + 1, SCCAnalysisRuns);
|
|
|
|
|
// The module analysis pass should be run three times.
|
|
|
|
|
EXPECT_EQ(3, ModuleAnalysisRuns);
|
|
|
|
|
// We run over four SCCs the first time. Then over the two new ones. Then the
|
|
|
|
|
// entire module is invalidated causing a full run over all seven. Then we
|
|
|
|
|
// fold three SCCs back to one, and then run over the whole module again.
|
|
|
|
|
EXPECT_EQ(4 + 2 + 7 + 1 + 4, IndirectSCCAnalysisRuns);
|
|
|
|
|
EXPECT_EQ(4 + 2 + 7 + 1 + 4, DoublyIndirectSCCAnalysisRuns);
|
|
|
|
|
|
|
|
|
|
// First we run over all six functions. Then we re-run it over three when we
|
|
|
|
|
// split their SCCs. Then we re-run over the whole module. Then we re-run
|
|
|
|
|
// over three functions merged back into a single SCC, and then over the
|
|
|
|
|
// whole module again.
|
|
|
|
|
EXPECT_EQ(6 + 2 + 6 + 3 + 6, FunctionAnalysisRuns);
|
|
|
|
|
|
|
|
|
|
// Re run the function analysis twice over the entire module, and then re-run
|
|
|
|
|
// it over the `(h3, h1, h2)` SCC due to invalidation. Then we re-un over
|
|
|
|
|
// three functions merged back into a single SCC, and then over the whole
|
|
|
|
|
// module.
|
|
|
|
|
EXPECT_EQ(6 + 2 + 6 + 3 + 6, IndirectFunctionAnalysisRuns);
|
|
|
|
|
}
|
2016-02-23 18:02:02 +08:00
|
|
|
}
|