From f96c3625c2cc9c580882b4914b293d9e64099022 Mon Sep 17 00:00:00 2001 From: Devang Patel Date: Tue, 17 Apr 2007 00:17:11 +0000 Subject: [PATCH] Remove "ModulePasses requiring FunctionPasses" from the list of future extensions. llvm-svn: 36186 --- llvm/docs/WritingAnLLVMPass.html | 29 +---------------------------- 1 file changed, 1 insertion(+), 28 deletions(-) diff --git a/llvm/docs/WritingAnLLVMPass.html b/llvm/docs/WritingAnLLVMPass.html index c9813ef11c52..8f2c7af1aa4e 100644 --- a/llvm/docs/WritingAnLLVMPass.html +++ b/llvm/docs/WritingAnLLVMPass.html @@ -103,8 +103,6 @@
  • Future extensions planned
    • @@ -1137,7 +1135,7 @@ For example:

        bool ModuleLevelPass::runOnModule(Module &M) {
      ...
-     DominatorTree &DT = getAnalysis<DominatorTree>(Function &F);
+     DominatorTree &DT = getAnalysis<DominatorTree>(Func);
      ...
    }
    @@ -1780,31 +1778,6 @@ places (for global resources). Although this is a simple extension, we simply haven't had time (or multiprocessor machines, thus a reason) to implement this. Despite that, we have kept the LLVM passes SMP ready, and you should too.

    - - - -
    -ModulePasses requiring FunctionPasses -
    - -
    - -

    Currently it is illegal for a ModulePass -to require a FunctionPass. This is because -there is only one instance of the FunctionPass object ever created, thus nowhere -to store information for all of the functions in the program at the same time. -Although this has come up a couple of times before, this has always been worked -around by factoring one big complicated pass into a global and an -interprocedural part, both of which are distinct. In the future, it would be -nice to have this though.

    - -

    Note that it is no problem for a FunctionPass to require the results of a ModulePass, only the other way around.

    - -
    -