[llvm-commits] Patch, enable reusing a module pass manager across multiple modules

[Chandler Carruth]

On Tue, Nov 13, 2012 at 3:51 PM, Pedro Artigas <partigas at apple.com> wrote:
> Hello All,
>
> The patch below is intended to enable reusing a module pass manager across multiple modules, the core idea is that module passes do not have to be reallocated but are just initialized and finalized before/after each run so that the allocated state can be persistent across multiple modules

I really like the idea of this, which I think Owen summarized well in
the discussion with Eric:

On Tue, Nov 13, 2012 at 5:42 PM, Owen Anderson <resistor at mac.com> wrote:
> All we're trying to do here is save the setup time for constructing a
> PassManager (slow because it has to plan the pass pipeline) in a process
> that is going to compile many translation units during the process'
> lifetime.


However, I don't really understand the current design you are
proposing yet, or how this patch moves toward it... You haven't really
commented clearly when it is that doInitialization and doFinalization
methods of the ModulePass are run -- that should probably be fixed --
but I see two possibilities:

1) They are run before (and after, resp.) each module is processed.
The discussion below seemed to indicate this behavior. If this is so,
I don't see why they are needed, we already have runOnModule, and
passes should keep any per-module state local to that function, the
same as a FunctionPass keeps any per-function state local to the
runOnFunction. This includes (for most function passes) cheaply
clearing state at the end, rather than forcing a deallocation and
reallocation.

2) They are run before any modules and after all modules. If this is
the semantic model, it's not clear why they are needed to achieve the
stated goal, or really at all. Wouldn't construction and destruction
work just as well? If not, the comments should explain why. Note that
the reason for a FunctionPass needing a non-constructor method in the
world where there was only ever one module per PassManager was to have
a handle to the module itself (AFAIK), and that wouldn't apply here...


I also think it is essential to add good comments to
FunctionPass::doInitialization and ::doFinalization to clarify that
they are now going to be run once-per-module, and generally they
become harder to understand as the names become more overloaded in
different pass contexts.