2013-11-09 21:09:08 +08:00
|
|
|
//===- llvm/unittest/IR/PassManager.cpp - PassManager tests ---------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/Assembly/Parser.h"
|
|
|
|
#include "llvm/IR/Function.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 {
|
|
|
|
|
2013-11-23 09:25:02 +08:00
|
|
|
class TestFunctionAnalysis {
|
2013-11-13 09:12:08 +08:00
|
|
|
public:
|
|
|
|
struct Result {
|
|
|
|
Result(int Count) : InstructionCount(Count) {}
|
|
|
|
int InstructionCount;
|
|
|
|
};
|
|
|
|
|
|
|
|
/// \brief Returns an opaque, unique ID for this pass type.
|
|
|
|
static void *ID() { return (void *)&PassID; }
|
|
|
|
|
2013-11-23 09:25:02 +08:00
|
|
|
TestFunctionAnalysis(int &Runs) : Runs(Runs) {}
|
2013-11-21 10:11:31 +08:00
|
|
|
|
2013-11-13 09:12:08 +08:00
|
|
|
/// \brief Run the analysis pass over the function and return a result.
|
2013-11-22 20:11:02 +08:00
|
|
|
Result run(Function *F, FunctionAnalysisManager *AM) {
|
2013-11-21 10:11:31 +08:00
|
|
|
++Runs;
|
2013-11-13 09:12:08 +08:00
|
|
|
int Count = 0;
|
|
|
|
for (Function::iterator BBI = F->begin(), BBE = F->end(); BBI != BBE; ++BBI)
|
|
|
|
for (BasicBlock::iterator II = BBI->begin(), IE = BBI->end(); II != IE;
|
|
|
|
++II)
|
|
|
|
++Count;
|
|
|
|
return Result(Count);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
/// \brief Private static data to provide unique ID.
|
|
|
|
static char PassID;
|
2013-11-21 10:11:31 +08:00
|
|
|
|
|
|
|
int &Runs;
|
2013-11-13 09:12:08 +08:00
|
|
|
};
|
|
|
|
|
2013-11-23 09:25:02 +08:00
|
|
|
char TestFunctionAnalysis::PassID;
|
2013-11-13 09:12:08 +08:00
|
|
|
|
2013-11-23 09:25:07 +08:00
|
|
|
class TestModuleAnalysis {
|
|
|
|
public:
|
|
|
|
struct Result {
|
|
|
|
Result(int Count) : FunctionCount(Count) {}
|
|
|
|
int FunctionCount;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void *ID() { return (void * )&PassID; }
|
|
|
|
|
|
|
|
TestModuleAnalysis(int &Runs) : Runs(Runs) {}
|
|
|
|
|
|
|
|
Result run(Module *M, ModuleAnalysisManager *AM) {
|
|
|
|
++Runs;
|
|
|
|
int Count = 0;
|
|
|
|
for (Module::iterator I = M->begin(), E = M->end(); I != E; ++I)
|
|
|
|
++Count;
|
|
|
|
return Result(Count);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
static char PassID;
|
|
|
|
|
|
|
|
int &Runs;
|
|
|
|
};
|
|
|
|
|
|
|
|
char TestModuleAnalysis::PassID;
|
|
|
|
|
2013-11-09 21:09:08 +08:00
|
|
|
struct TestModulePass {
|
|
|
|
TestModulePass(int &RunCount) : RunCount(RunCount) {}
|
|
|
|
|
2013-11-20 19:31:50 +08:00
|
|
|
PreservedAnalyses run(Module *M) {
|
2013-11-09 21:09:08 +08:00
|
|
|
++RunCount;
|
2013-11-20 19:31:50 +08:00
|
|
|
return PreservedAnalyses::none();
|
2013-11-09 21:09:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int &RunCount;
|
|
|
|
};
|
|
|
|
|
2013-11-21 18:53:05 +08:00
|
|
|
struct TestPreservingModulePass {
|
|
|
|
PreservedAnalyses run(Module *M) {
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
struct TestMinPreservingModulePass {
|
2013-11-23 08:38:42 +08:00
|
|
|
PreservedAnalyses run(Module *M, ModuleAnalysisManager *AM) {
|
2013-11-21 18:53:05 +08:00
|
|
|
PreservedAnalyses PA;
|
2013-11-23 08:38:42 +08:00
|
|
|
|
2013-11-23 09:25:07 +08:00
|
|
|
// Force running an analysis.
|
|
|
|
(void)AM->getResult<TestModuleAnalysis>(M);
|
2013-11-23 08:38:42 +08:00
|
|
|
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
llvm-svn: 195400
2013-11-22 08:43:29 +08:00
|
|
|
PA.preserve<FunctionAnalysisManagerModuleProxy>();
|
2013-11-21 18:53:05 +08:00
|
|
|
return PA;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2013-11-09 21:09:08 +08:00
|
|
|
struct TestFunctionPass {
|
2013-11-23 08:38:42 +08:00
|
|
|
TestFunctionPass(int &RunCount, int &AnalyzedInstrCount,
|
2013-11-23 09:25:07 +08:00
|
|
|
int &AnalyzedFunctionCount,
|
2013-11-23 08:38:42 +08:00
|
|
|
bool OnlyUseCachedResults = false)
|
|
|
|
: RunCount(RunCount), AnalyzedInstrCount(AnalyzedInstrCount),
|
2013-11-23 09:25:07 +08:00
|
|
|
AnalyzedFunctionCount(AnalyzedFunctionCount),
|
2013-11-23 08:38:42 +08:00
|
|
|
OnlyUseCachedResults(OnlyUseCachedResults) {}
|
2013-11-09 21:09:08 +08:00
|
|
|
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
llvm-svn: 195400
2013-11-22 08:43:29 +08:00
|
|
|
PreservedAnalyses run(Function *F, FunctionAnalysisManager *AM) {
|
2013-11-09 21:09:08 +08:00
|
|
|
++RunCount;
|
2013-11-13 09:12:08 +08:00
|
|
|
|
2013-11-23 09:25:07 +08:00
|
|
|
const ModuleAnalysisManager &MAM =
|
|
|
|
AM->getResult<ModuleAnalysisManagerFunctionProxy>(F).getManager();
|
|
|
|
if (const TestModuleAnalysis::Result *TMA =
|
|
|
|
MAM.getCachedResult<TestModuleAnalysis>(F->getParent()))
|
|
|
|
AnalyzedFunctionCount += TMA->FunctionCount;
|
|
|
|
|
2013-11-23 08:38:42 +08:00
|
|
|
if (OnlyUseCachedResults) {
|
|
|
|
// Hack to force the use of the cached interface.
|
2013-11-23 09:25:02 +08:00
|
|
|
if (const TestFunctionAnalysis::Result *AR =
|
|
|
|
AM->getCachedResult<TestFunctionAnalysis>(F))
|
2013-11-23 08:38:42 +08:00
|
|
|
AnalyzedInstrCount += AR->InstructionCount;
|
|
|
|
} else {
|
|
|
|
// Typical path just runs the analysis as needed.
|
2013-11-23 09:25:02 +08:00
|
|
|
const TestFunctionAnalysis::Result &AR = AM->getResult<TestFunctionAnalysis>(F);
|
2013-11-23 08:38:42 +08:00
|
|
|
AnalyzedInstrCount += AR.InstructionCount;
|
|
|
|
}
|
2013-11-13 09:12:08 +08:00
|
|
|
|
2013-11-21 10:11:31 +08:00
|
|
|
return PreservedAnalyses::all();
|
2013-11-09 21:09:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int &RunCount;
|
2013-11-13 09:12:08 +08:00
|
|
|
int &AnalyzedInstrCount;
|
2013-11-23 09:25:07 +08:00
|
|
|
int &AnalyzedFunctionCount;
|
2013-11-23 08:38:42 +08:00
|
|
|
bool OnlyUseCachedResults;
|
2013-11-09 21:09:08 +08:00
|
|
|
};
|
|
|
|
|
2013-11-23 07:38:07 +08:00
|
|
|
// A test function pass that invalidates all function analyses for a function
|
|
|
|
// with a specific name.
|
|
|
|
struct TestInvalidationFunctionPass {
|
|
|
|
TestInvalidationFunctionPass(StringRef FunctionName) : Name(FunctionName) {}
|
|
|
|
|
|
|
|
PreservedAnalyses run(Function *F) {
|
|
|
|
return F->getName() == Name ? PreservedAnalyses::none()
|
|
|
|
: PreservedAnalyses::all();
|
|
|
|
}
|
|
|
|
|
|
|
|
StringRef Name;
|
|
|
|
};
|
|
|
|
|
2013-11-09 21:09:08 +08:00
|
|
|
Module *parseIR(const char *IR) {
|
|
|
|
LLVMContext &C = getGlobalContext();
|
|
|
|
SMDiagnostic Err;
|
|
|
|
return ParseAssemblyString(IR, 0, Err, C);
|
|
|
|
}
|
|
|
|
|
|
|
|
class PassManagerTest : public ::testing::Test {
|
|
|
|
protected:
|
|
|
|
OwningPtr<Module> M;
|
|
|
|
|
|
|
|
public:
|
|
|
|
PassManagerTest()
|
|
|
|
: M(parseIR("define void @f() {\n"
|
|
|
|
"entry:\n"
|
|
|
|
" call void @g()\n"
|
|
|
|
" call void @h()\n"
|
|
|
|
" ret void\n"
|
|
|
|
"}\n"
|
|
|
|
"define void @g() {\n"
|
|
|
|
" ret void\n"
|
|
|
|
"}\n"
|
|
|
|
"define void @h() {\n"
|
|
|
|
" ret void\n"
|
|
|
|
"}\n")) {}
|
|
|
|
};
|
|
|
|
|
|
|
|
TEST_F(PassManagerTest, Basic) {
|
2013-11-21 10:11:31 +08:00
|
|
|
FunctionAnalysisManager FAM;
|
2013-11-23 09:25:07 +08:00
|
|
|
int FunctionAnalysisRuns = 0;
|
|
|
|
FAM.registerPass(TestFunctionAnalysis(FunctionAnalysisRuns));
|
2013-11-21 10:11:31 +08:00
|
|
|
|
|
|
|
ModuleAnalysisManager MAM;
|
2013-11-23 09:25:07 +08:00
|
|
|
int ModuleAnalysisRuns = 0;
|
|
|
|
MAM.registerPass(TestModuleAnalysis(ModuleAnalysisRuns));
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
llvm-svn: 195400
2013-11-22 08:43:29 +08:00
|
|
|
MAM.registerPass(FunctionAnalysisManagerModuleProxy(FAM));
|
2013-11-23 09:25:07 +08:00
|
|
|
FAM.registerPass(ModuleAnalysisManagerFunctionProxy(MAM));
|
2013-11-21 10:11:31 +08:00
|
|
|
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
llvm-svn: 195400
2013-11-22 08:43:29 +08:00
|
|
|
ModulePassManager MPM;
|
2013-11-13 09:12:08 +08:00
|
|
|
|
2013-11-21 10:11:31 +08:00
|
|
|
// Count the runs over a Function.
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
llvm-svn: 195400
2013-11-22 08:43:29 +08:00
|
|
|
FunctionPassManager FPM1;
|
2013-11-21 10:11:31 +08:00
|
|
|
int FunctionPassRunCount1 = 0;
|
|
|
|
int AnalyzedInstrCount1 = 0;
|
2013-11-23 09:25:07 +08:00
|
|
|
int AnalyzedFunctionCount1 = 0;
|
|
|
|
FPM1.addPass(TestFunctionPass(FunctionPassRunCount1, AnalyzedInstrCount1,
|
|
|
|
AnalyzedFunctionCount1));
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
llvm-svn: 195400
2013-11-22 08:43:29 +08:00
|
|
|
MPM.addPass(createModuleToFunctionPassAdaptor(FPM1));
|
2013-11-09 21:09:08 +08:00
|
|
|
|
|
|
|
// Count the runs over a module.
|
|
|
|
int ModulePassRunCount = 0;
|
|
|
|
MPM.addPass(TestModulePass(ModulePassRunCount));
|
|
|
|
|
2013-11-21 10:11:31 +08:00
|
|
|
// Count the runs over a Function in a separate manager.
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
llvm-svn: 195400
2013-11-22 08:43:29 +08:00
|
|
|
FunctionPassManager FPM2;
|
2013-11-21 10:11:31 +08:00
|
|
|
int FunctionPassRunCount2 = 0;
|
|
|
|
int AnalyzedInstrCount2 = 0;
|
2013-11-23 09:25:07 +08:00
|
|
|
int AnalyzedFunctionCount2 = 0;
|
|
|
|
FPM2.addPass(TestFunctionPass(FunctionPassRunCount2, AnalyzedInstrCount2,
|
|
|
|
AnalyzedFunctionCount2));
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
llvm-svn: 195400
2013-11-22 08:43:29 +08:00
|
|
|
MPM.addPass(createModuleToFunctionPassAdaptor(FPM2));
|
2013-11-09 21:09:08 +08:00
|
|
|
|
2013-11-23 07:38:07 +08:00
|
|
|
// A third function pass manager but with only preserving intervening passes
|
|
|
|
// and with a function pass that invalidates exactly one analysis.
|
2013-11-21 18:53:05 +08:00
|
|
|
MPM.addPass(TestPreservingModulePass());
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
llvm-svn: 195400
2013-11-22 08:43:29 +08:00
|
|
|
FunctionPassManager FPM3;
|
2013-11-21 18:53:05 +08:00
|
|
|
int FunctionPassRunCount3 = 0;
|
|
|
|
int AnalyzedInstrCount3 = 0;
|
2013-11-23 09:25:07 +08:00
|
|
|
int AnalyzedFunctionCount3 = 0;
|
|
|
|
FPM3.addPass(TestFunctionPass(FunctionPassRunCount3, AnalyzedInstrCount3,
|
|
|
|
AnalyzedFunctionCount3));
|
2013-11-23 07:38:07 +08:00
|
|
|
FPM3.addPass(TestInvalidationFunctionPass("f"));
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
llvm-svn: 195400
2013-11-22 08:43:29 +08:00
|
|
|
MPM.addPass(createModuleToFunctionPassAdaptor(FPM3));
|
2013-11-21 18:53:05 +08:00
|
|
|
|
|
|
|
// A fourth function pass manager but with a minimal intervening passes.
|
|
|
|
MPM.addPass(TestMinPreservingModulePass());
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
llvm-svn: 195400
2013-11-22 08:43:29 +08:00
|
|
|
FunctionPassManager FPM4;
|
2013-11-21 18:53:05 +08:00
|
|
|
int FunctionPassRunCount4 = 0;
|
|
|
|
int AnalyzedInstrCount4 = 0;
|
2013-11-23 09:25:07 +08:00
|
|
|
int AnalyzedFunctionCount4 = 0;
|
|
|
|
FPM4.addPass(TestFunctionPass(FunctionPassRunCount4, AnalyzedInstrCount4,
|
|
|
|
AnalyzedFunctionCount4));
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
llvm-svn: 195400
2013-11-22 08:43:29 +08:00
|
|
|
MPM.addPass(createModuleToFunctionPassAdaptor(FPM4));
|
2013-11-21 18:53:05 +08:00
|
|
|
|
2013-11-23 08:38:42 +08:00
|
|
|
// A fifth function pass manager but which uses only cached results.
|
|
|
|
FunctionPassManager FPM5;
|
|
|
|
int FunctionPassRunCount5 = 0;
|
|
|
|
int AnalyzedInstrCount5 = 0;
|
2013-11-23 09:25:07 +08:00
|
|
|
int AnalyzedFunctionCount5 = 0;
|
2013-11-23 08:38:42 +08:00
|
|
|
FPM5.addPass(TestInvalidationFunctionPass("f"));
|
|
|
|
FPM5.addPass(TestFunctionPass(FunctionPassRunCount5, AnalyzedInstrCount5,
|
2013-11-23 09:25:07 +08:00
|
|
|
AnalyzedFunctionCount5,
|
2013-11-23 08:38:42 +08:00
|
|
|
/*OnlyUseCachedResults=*/true));
|
|
|
|
MPM.addPass(createModuleToFunctionPassAdaptor(FPM5));
|
|
|
|
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
llvm-svn: 195400
2013-11-22 08:43:29 +08:00
|
|
|
MPM.run(M.get(), &MAM);
|
2013-11-21 10:11:31 +08:00
|
|
|
|
|
|
|
// Validate module pass counters.
|
2013-11-09 21:09:08 +08:00
|
|
|
EXPECT_EQ(1, ModulePassRunCount);
|
2013-11-21 10:11:31 +08:00
|
|
|
|
2013-11-23 07:38:07 +08:00
|
|
|
// Validate all function pass counter sets are the same.
|
2013-11-21 10:11:31 +08:00
|
|
|
EXPECT_EQ(3, FunctionPassRunCount1);
|
|
|
|
EXPECT_EQ(5, AnalyzedInstrCount1);
|
2013-11-23 09:25:07 +08:00
|
|
|
EXPECT_EQ(0, AnalyzedFunctionCount1);
|
2013-11-21 10:11:31 +08:00
|
|
|
EXPECT_EQ(3, FunctionPassRunCount2);
|
|
|
|
EXPECT_EQ(5, AnalyzedInstrCount2);
|
2013-11-23 09:25:07 +08:00
|
|
|
EXPECT_EQ(0, AnalyzedFunctionCount2);
|
2013-11-21 18:53:05 +08:00
|
|
|
EXPECT_EQ(3, FunctionPassRunCount3);
|
|
|
|
EXPECT_EQ(5, AnalyzedInstrCount3);
|
2013-11-23 09:25:07 +08:00
|
|
|
EXPECT_EQ(0, AnalyzedFunctionCount3);
|
2013-11-21 18:53:05 +08:00
|
|
|
EXPECT_EQ(3, FunctionPassRunCount4);
|
|
|
|
EXPECT_EQ(5, AnalyzedInstrCount4);
|
2013-11-23 09:25:07 +08:00
|
|
|
EXPECT_EQ(0, AnalyzedFunctionCount4);
|
2013-11-23 08:38:42 +08:00
|
|
|
EXPECT_EQ(3, FunctionPassRunCount5);
|
|
|
|
EXPECT_EQ(2, AnalyzedInstrCount5); // Only 'g' and 'h' were cached.
|
2013-11-23 09:25:07 +08:00
|
|
|
EXPECT_EQ(0, AnalyzedFunctionCount5);
|
2013-11-21 10:11:31 +08:00
|
|
|
|
2013-11-23 07:38:07 +08:00
|
|
|
// Validate the analysis counters:
|
|
|
|
// first run over 3 functions, then module pass invalidates
|
|
|
|
// second run over 3 functions, nothing invalidates
|
|
|
|
// third run over 0 functions, but 1 function invalidated
|
|
|
|
// fourth run over 1 function
|
2013-11-23 09:25:07 +08:00
|
|
|
EXPECT_EQ(7, FunctionAnalysisRuns);
|
|
|
|
|
|
|
|
EXPECT_EQ(1, ModuleAnalysisRuns);
|
2013-11-09 21:09:08 +08:00
|
|
|
}
|
|
|
|
}
|