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

[Evan Cheng]

On Nov 14, 2012, at 3:01 AM, Chandler Carruth <chandlerc at google.com> wrote:

> 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.

This is the usage model but what you described doesn't work for passes that keep states for the lifetime of the entire compilation pipeline. 

Evan

> 
> 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.
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits