From 62b442d3784c3d1c8468230c8df2bd853f763de8 Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Sat, 18 Sep 2004 16:16:28 +0000 Subject: [PATCH] Misha implemented the ModuleProvider interface back in 9/18/2003. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@16394 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/WritingAnLLVMPass.html | 28 ---------------------------- 1 file changed, 28 deletions(-) diff --git a/docs/WritingAnLLVMPass.html b/docs/WritingAnLLVMPass.html index cb9729f975f..0cc779243e4 100644 --- a/docs/WritingAnLLVMPass.html +++ b/docs/WritingAnLLVMPass.html @@ -89,7 +89,6 @@
  • Future extensions planned
  • @@ -1537,33 +1536,6 @@ Despite that, we have kept the LLVM passes SMP ready, and you should too.

    - -
    - A new ModuleSource interface -
    - -
    - -

    Currently, the PassManager's run method takes a Module -as input, and runs all of the passes on this module. The problem with this -approach is that none of the PassManager features can be used for -timing and debugging the actual loading of the module from disk or -standard input.

    - -

    To solve this problem, eventually the PassManager class will accept -a ModuleSource object instead of a Module itself. When complete, this -will also allow for streaming of functions out of the bytecode representation, -allowing us to avoid holding the entire program in memory at once if we only are -dealing with FunctionPasses.

    - -

    As part of a different issue, eventually the bytecode loader will be extended -to allow on-demand loading of functions from the bytecode representation, in -order to better support the runtime reoptimizer. The bytecode format is already -capable of this, the loader just needs to be reworked a bit.

    - -
    -
    Passes requiring FunctionPasses -- 2.34.1