2013-11-09 13:09:08 +00: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-13 01:12:08 +00:00
|
|
|
class TestAnalysisPass {
|
|
|
|
public:
|
|
|
|
typedef Function IRUnitT;
|
|
|
|
|
|
|
|
struct Result {
|
|
|
|
Result(int Count) : InstructionCount(Count) {}
|
|
|
|
bool invalidate(Function *) { return true; }
|
|
|
|
int InstructionCount;
|
|
|
|
};
|
|
|
|
|
|
|
|
/// \brief Returns an opaque, unique ID for this pass type.
|
|
|
|
static void *ID() { return (void *)&PassID; }
|
|
|
|
|
|
|
|
/// \brief Run the analysis pass over the function and return a result.
|
|
|
|
Result run(Function *F) {
|
|
|
|
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;
|
|
|
|
};
|
|
|
|
|
|
|
|
char TestAnalysisPass::PassID;
|
|
|
|
|
2013-11-09 13:09:08 +00:00
|
|
|
struct TestModulePass {
|
|
|
|
TestModulePass(int &RunCount) : RunCount(RunCount) {}
|
|
|
|
|
|
|
|
bool run(Module *M) {
|
|
|
|
++RunCount;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
int &RunCount;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct TestFunctionPass {
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
TestFunctionPass(FunctionAnalysisManager &AM, int &RunCount,
|
|
|
|
int &AnalyzedInstrCount)
|
|
|
|
: AM(AM), RunCount(RunCount), AnalyzedInstrCount(AnalyzedInstrCount) {}
|
2013-11-09 13:09:08 +00:00
|
|
|
|
|
|
|
bool run(Function *F) {
|
|
|
|
++RunCount;
|
2013-11-13 01:12:08 +00:00
|
|
|
|
|
|
|
const TestAnalysisPass::Result &AR = AM.getResult<TestAnalysisPass>(F);
|
|
|
|
AnalyzedInstrCount += AR.InstructionCount;
|
|
|
|
|
2013-11-09 13:09:08 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
FunctionAnalysisManager &AM;
|
2013-11-09 13:09:08 +00:00
|
|
|
int &RunCount;
|
2013-11-13 01:12:08 +00:00
|
|
|
int &AnalyzedInstrCount;
|
2013-11-09 13:09:08 +00: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) {
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
FunctionAnalysisManager AM;
|
|
|
|
AM.registerPass(TestAnalysisPass());
|
2013-11-13 01:12:08 +00:00
|
|
|
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
ModulePassManager MPM;
|
2013-11-13 01:12:08 +00:00
|
|
|
FunctionPassManager FPM(&AM);
|
2013-11-09 13:09:08 +00:00
|
|
|
|
|
|
|
// Count the runs over a module.
|
|
|
|
int ModulePassRunCount = 0;
|
|
|
|
MPM.addPass(TestModulePass(ModulePassRunCount));
|
|
|
|
|
|
|
|
// Count the runs over a Function.
|
|
|
|
int FunctionPassRunCount = 0;
|
2013-11-13 01:12:08 +00:00
|
|
|
int AnalyzedInstrCount = 0;
|
|
|
|
FPM.addPass(TestFunctionPass(AM, FunctionPassRunCount, AnalyzedInstrCount));
|
2013-11-20 04:39:16 +00:00
|
|
|
MPM.addPass(createModuleToFunctionPassAdaptor(FPM));
|
2013-11-09 13:09:08 +00:00
|
|
|
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
MPM.run(M.get());
|
2013-11-09 13:09:08 +00:00
|
|
|
EXPECT_EQ(1, ModulePassRunCount);
|
|
|
|
EXPECT_EQ(3, FunctionPassRunCount);
|
2013-11-13 01:12:08 +00:00
|
|
|
EXPECT_EQ(5, AnalyzedInstrCount);
|
2013-11-09 13:09:08 +00:00
|
|
|
}
|
|
|
|
}
|