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

Evan Cheng evan.cheng at apple.com
Wed Nov 14 10:03:37 PST 2012


I've been thinking about this a bit more. Initially I liked the doInitialization and doFinalization additions since they are consistent with function modules API. However this change may require changes to existing module passes (moving initialization code from ctor to doInitialization) and tools. This is a subtle API change and can easily break out of tree code. Perhaps a better change would be an API addition, e.g. resetState(). That would not require any change to any existing pass and tool. Once the tools which want to reuse module passes would need changes.

Evan

On Nov 14, 2012, at 8:52 AM, Evan Cheng <evan.cheng at apple.com> wrote:

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




More information about the llvm-commits mailing list