From f348c9782c5c31309dfd2d04e3dbee21fefe07ff Mon Sep 17 00:00:00 2001
From: Chandler Carruth <chandlerc@gmail.com>
Date: Wed, 13 Nov 2013 01:12:08 +0000
Subject: Introduce an AnalysisManager which is like a pass manager but with a
 lot more smarts in it. This is where most of the interesting logic that used
 to live in the implicit-scheduling-hackery of the old pass manager will live.

Like the previous commits, note that this is a very early prototype!
I expect substantial changes before this is ready to use.

The core of the design is the following:

- We have an AnalysisManager which can be used across a series of
  passes over a module.
- The code setting up a pass pipeline registers the analyses available
  with the manager.
- Individual transform passes can check than an analysis manager
  provides the analyses they require in order to fail-fast.
- There is *no* implicit registration or scheduling.
- Analysis passes are different from other passes: they produce an
  analysis result that is cached and made available via the analysis
  manager.
- Cached results are invalidated automatically by the pass managers.
- When a transform pass requests an analysis result, either the analysis
  is run to produce the result or a cached result is provided.

There are a few aspects of this design that I *know* will change in
subsequent commits:
- Currently there is no "preservation" system, that needs to be added.
- All of the analysis management should move up to the analysis library.
- The analysis management needs to support at least SCC passes. Maybe
  loop passes. Living in the analysis library will facilitate this.
- Need support for analyses which are *both* module and function passes.
- Need support for pro-actively running module analyses to have cached
  results within a function pass manager.
- Need a clear design for "immutable" passes.
- Need support for requesting cached results when available and not
  re-running the pass even if that would be necessary.
- Need more thorough testing of all of this infrastructure.

There are other aspects that I view as open questions I'm hoping to
resolve as I iterate a bit on the infrastructure, and especially as
I start writing actual passes against this.
- Should we have separate management layers for function, module, and
  SCC analyses? I think "yes", but I'm not yet ready to switch the code.
  Adding SCC support will likely resolve this definitively.
- How should the 'require' functionality work? Should *that* be the only
  way to request results to ensure that passes always require things?
- How should preservation work?
- Probably some other things I'm forgetting. =]

Look forward to more patches in shorter order now that this is in place.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194538 91177308-0d34-0410-b5e6-96231b3b80d8
---
 unittests/IR/PassManagerTest.cpp | 52 ++++++++++++++++++++++++++++++++++++----
 1 file changed, 48 insertions(+), 4 deletions(-)

(limited to 'unittests')

diff --git a/unittests/IR/PassManagerTest.cpp b/unittests/IR/PassManagerTest.cpp
index f2e04d9e77..8eec0eca7b 100644
--- a/unittests/IR/PassManagerTest.cpp
+++ b/unittests/IR/PassManagerTest.cpp
@@ -19,6 +19,36 @@ using namespace llvm;
 
 namespace {
 
+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;
+
 struct TestModulePass {
   TestModulePass(int &RunCount) : RunCount(RunCount) {}
 
@@ -31,14 +61,23 @@ struct TestModulePass {
 };
 
 struct TestFunctionPass {
-  TestFunctionPass(int &RunCount) : RunCount(RunCount) {}
+  TestFunctionPass(AnalysisManager &AM, int &RunCount, int &AnalyzedInstrCount)
+      : AM(AM), RunCount(RunCount), AnalyzedInstrCount(AnalyzedInstrCount) {
+    AM.requireAnalysisPass<TestAnalysisPass>();
+  }
 
   bool run(Function *F) {
     ++RunCount;
+
+    const TestAnalysisPass::Result &AR = AM.getResult<TestAnalysisPass>(F);
+    AnalyzedInstrCount += AR.InstructionCount;
+
     return true;
   }
 
+  AnalysisManager &AM;
   int &RunCount;
+  int &AnalyzedInstrCount;
 };
 
 Module *parseIR(const char *IR) {
@@ -68,8 +107,11 @@ public:
 };
 
 TEST_F(PassManagerTest, Basic) {
-  ModulePassManager MPM(M.get());
-  FunctionPassManager FPM;
+  AnalysisManager AM(M.get());
+  AM.registerAnalysisPass(TestAnalysisPass());
+
+  ModulePassManager MPM(M.get(), &AM);
+  FunctionPassManager FPM(&AM);
 
   // Count the runs over a module.
   int ModulePassRunCount = 0;
@@ -77,12 +119,14 @@ TEST_F(PassManagerTest, Basic) {
 
   // Count the runs over a Function.
   int FunctionPassRunCount = 0;
-  FPM.addPass(TestFunctionPass(FunctionPassRunCount));
+  int AnalyzedInstrCount = 0;
+  FPM.addPass(TestFunctionPass(AM, FunctionPassRunCount, AnalyzedInstrCount));
   MPM.addPass(FPM);
 
   MPM.run();
   EXPECT_EQ(1, ModulePassRunCount);
   EXPECT_EQ(3, FunctionPassRunCount);
+  EXPECT_EQ(5, AnalyzedInstrCount);
 }
 
 }
-- 
cgit v1.2.3