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

[Chandler Carruth]

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!

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