[llvm-commits] Improvements to PassManager

Pedro Artigas partigas at apple.com
Mon Nov 26 11:27:43 PST 2012


Hello All/Chandler,

The patch below has the corrections on the FIXME comments you suggested. The need for doFinalization inside the runOnModule of the FPPassManager is the very line that makes ASAN work today, that is why it is still there.

Thanks

Pedro

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121126/965d1f2a/attachment.txt>
-------------- next part --------------



On Nov 26, 2012, at 11:16 AM, Pedro Artigas <partigas at apple.com> wrote:

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