[llvm-commits] Improvements to PassManager

[Pedro Artigas]

Hello All/Chandler,

I Agree that the model should be more restrictive than what it is today, the order:

- call doInitialization passing the module for every pass, order among different passes is arbitrary
- call run on every pass, enforcing the ordering among passes
- call doFinalization passing the module for every pass, order among different passes is arbitrary

Was the intention all along, I believe.  Otherwise transformations on the module by passes may interfere with initialization/finalization tasks.

Thanks

Pedro

On Nov 26, 2012, at 10:59 AM, Chandler Carruth <chandlerc at google.com> wrote:

> 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