[llvm-commits] Patch: add doInitialization and doFinalization to module passes

[Evan Cheng]

On Nov 14, 2012, at 4:44 PM, Chandler Carruth <chandlerc at google.com> wrote:

> On Wed, Nov 14, 2012 at 2:40 PM, Pedro Artigas <partigas at apple.com> wrote:
>> Hello All,
>> 
>> Yesterday's e-mail caused some concerns, therefore we improved the patch to re-write all in-tree projects to use the doInitialization/run/doFinalization scheme for module passes just like it is done for function passes.
> 
> So, it would help a lot to not fork the email thread. I asked a lot of
> questions on the original one that weren't quite answered. That said,
> I think I have deduced them from the patch itself, see below.
> 
> 
>> Right now no passes follow this model but the skeleton should make it clear how the model operates and how to adapt module passes to follow the model, the idea is that a pass would do basic immutable allocation and variable set up in the constructor, would do minimal variable set up on the doInitialization and doFinalization would free all the extra memory allocated to store the state of the prior module, bringing the module pass to the state right after construction so it can be reused for a future module.
> 
> Ok, so this isn't quite what I was hoping for in terms of clear. I
> think the semantics for when these methods are expected to be invoked
> needs to be really clearly documented in their comments as at least I
> myself (and several others I suspect) had the wrong idea. I'll explain
> what I've deduced, and let's see if that matches your expectation.
> 
> My new understanding is that these methods bracket a *single* module
> being run through a complete pass manager. Before the first pass
> (module or otherwise) is run, every pass gets doInitialization, and
> after the last pass (module or otherwise) is run, every pass gets a
> doFinalization call. This allows per-module setup and teardown that is
> distinct from a per *run* setup and tear down. Notably, you might run
> a module pass (say, globaldce) more than once *on a single module*,
> making runOnModule not a good method to do per-module setup and
> teardown.
> 
> Does this match with your intended design? If so, comments please!

I agree on better documentation. The current pass manager design is extremely confusing. Although this change isn't meant to solve all of the problems with PM, we should improve the documentation incrementally.

> 
> Also, if this matches with your intent, I think two interface aspects
> should change:
> 
> 1) This should be the same methods that FunctionPass has, so they
> become methods on Pass itself.

That's already the case. They are methods on Pass as well as PassManager.

Pedro, since FunctionPassManager inherits from PassManager, I think you should remove the doInitialization and doFinalization declaration from FunctionPassManager now.

Evan


> 2) They should always accept the module reference just like
> FunctionPass::doInitialization and FunctionPass:doFinalization so that
> passes can (for example) add global variables to the module for use
> across all runs of that pass.
> 
> 
> Finally, some comments on the patch itself:
> 
> +  /// doInitialization - Virtual method overridden by subclasses to do
> +  /// any necessary initialization.
> +  ///
> 
> Please follow the new coding conventions for doxygen comments.
> 
> +  virtual bool doInitialization(void)  { return false; }
> 
> No need for (void) parameter list.... but this probably will be
> obviated by the move to match the interface on FunctionPass.
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits