From: Devang Patel Date: Tue, 17 Apr 2007 00:17:11 +0000 (+0000) Subject: Remove "ModulePasses requiring FunctionPasses" from the list of future X-Git-Url: http://plrg.eecs.uci.edu/git/?a=commitdiff_plain;h=f23de11c29db407793474ab645ed5994678d743f;p=oota-llvm.git Remove "ModulePasses requiring FunctionPasses" from the list of future extensions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36186 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/docs/WritingAnLLVMPass.html b/docs/WritingAnLLVMPass.html index c9813ef11c5..8f2c7af1aa4 100644 --- a/docs/WritingAnLLVMPass.html +++ b/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.

    - -
    -