[llvm-commits] Improvements to PassManager

[Chandler Carruth]

On Mon, Nov 26, 2012 at 9:39 AM, Pedro Artigas <partigas at apple.com> wrote:
>
> Hello All,
>
>
> To summarize the thread and make sure everybody is on the same page I will
> repeat some information below.
>
> - doInitialization and doFinalization are expected to be called before/after
> runOn???? for each pass on a given module, if more than one module exist in
> the compilation it will be called multiple times. No other assumption
> exists. (that is, for example, doFinalization may be called before or after
> runOn??? of other, unrelated, passes)

Long term, I actually think a more restrictive (but different from
what ASan needs) model would be better:

doInitialization and doFinalization are expected to be called
before/after *all* runOn??? for any pass on a given module. That is,
the pass manager should provide the following sequencing.

For each module in the compilation:
1) All passes in the manager have doInitialization called with a
reference to the module.
2) The manager's runOn??? sequencing is started and runs in the
sequence just as it does today.
3) All passes in the manager have doFinalization called with a
reference to the module.

This allows the doInitialization and doFinalization methods to perform
per-module resource allocation and collection in a demonstrably safe
way. Any other ordering seems much more brittle and hard to explain to
pass authors.

> - ASAN violates this model and it is currently being fixed to split the part
> that does transformations on the module in doFinalization into a separate
> module pass (where the code to transform will be called in the run function
> on the module and, therefore, has proper ordering with other passes)

Yes. =] And many thanks to Kostya for tackling this on short notice.

> - the short term plan is to workaround the limitation in ASAN by imposing a
> more restrictive ordering in the doFinalization for function passes (must be
> run after runOnFunction on each function) so that ASAN works for now, but
> this limitation should be lifted in the future.
>
> If the above is the conclusion I am happy to implement item #3 and defer the
> fixing of ASAN until time permits. It will unblock me.

I also really like this short-term plan. Clearly you need to be
unblocked. =] I'm interested in your thoughts on the long-term side of
things.

-Chandler