[llvm-commits] Improvements to PassManager

[Kostya Serebryany]

On Mon, Nov 19, 2012 at 4:33 PM, Chandler Carruth <chandlerc at google.com>wrote:

> FYI, it shouldn't be moved back to a module pass. I'm just suggesting the
> logic in doFinalization should be lifted into a module pass.
>
You mean split the AddressSanitizer class into two? This will cause some
pain.
There are things computed at doInitialization or at runOnFunction, and then
used in doFinalization.
E.g. DynamicallyInitializedGlobals will need to be computed twice.
GlobalsCreatedByAsan will have to be replaced with some other way to mark
globals created by asan (use metadata nodes? match name strings?)







> On Nov 19, 2012 4:22 AM, "Kostya Serebryany" <kcc at google.com> wrote:
>
>>
>>
>> On Mon, Nov 19, 2012 at 4:08 PM, Chandler Carruth <chandlerc at google.com>wrote:
>>
>>> FWIW, similar to Evan's comments, I would be interested to see what
>>> variation of the patch would satisfy the immediate needs of ASan,
>>> mostly because I don't want to block this on the fixing the much
>>> deeper issues w/ the pass manager.
>>>
>>
>> I can move asan back to ModulePass if that helps.
>> It was a ModulePass until recently, I changed it to FunctionPass because
>> it simplified using ScalarEvolution, which is a FunctionPass too.
>> Apparently, this chage was wrong, although I still not see why :(
>> (We still did not apply the patch with ScalarEvolution, so moving asan
>> back to FunctionPass should not break anything)
>>
>> --kcc
>>
>>
>>
>>>
>>> However, having looked at the *specific* case of ASan, I think it is
>>> likely playing fast and loose with the finalization step, and that
>>> step should be moved to a module pass. Are the issues you're seeing
>>> strictly a consequence of the finalization step? If so, I can work on
>>> splitting it into a module pass to help unblock you.
>>>
>>>
>>> Everything below is trying to get a better understanding of the
>>> underlying issues, and so may not be relevant in the short-term...
>>>
>>> On Sun, Nov 18, 2012 at 3:37 PM, Nick Lewycky <nicholas at mxc.ca> wrote:
>>> > Pedro Artigas wrote:
>>> >>
>>> >> Hello evan,
>>> >>
>>> >> I believe that there should be no ordering assumption between any
>>> >> doFinalization/doInitialization calls, that is what got us in trouble
>>> in the
>>> >> first place. The current assumption is that doFinalization of
>>> >> AddressSanitizer is run before runOnModule of the printer which is,
>>> AFAIK,
>>> >> an unreasonable assumption and a current implementation detail.
>>> >
>>> >
>>> > Hi Pedro, I think I'm responsible for the way that ASAN uses
>>> > doInitialization/doFinalization, by suggesting it in review when the
>>> pass
>>> > was added.
>>> >
>>> > My understanding is that function passes are expected to do things to
>>> the
>>> > module in their init/finalize functions that they can't do in
>>> runOnFunction
>>> > -- in this case, creating and then cleaning up the function
>>> declarations.
>>> > Trying to do that in runOnFunction would break parallel runs of
>>> function
>>> > passes.
>>>
>>> My perspective on the init/finalize functions is somewhat different:
>>> 0) They should have a common interface across all passes: function,
>>> module, and BB. I think the current differences should be fixed.
>>> 1) They should get a handle to the module being processed.
>>> 2) They should be called exactly once per module, no matter how many
>>> times the pass appears in the optimization pipeline.
>>> 3) The init variant should be called before any pass's 'runOnFoo'
>>> method is called, and the finalize after every runOnFoo.
>>>
>>> The goal here is to allow once-per-module setup and teardown of common
>>> infrastructure used in a pass. It is *not* for the purpose of doing
>>> transformations of entities within the pass, however merely adding
>>> declarations of functions (or even adding entirely new functions)
>>> seems an excellent use of the init.
>>>
>>> I think ASan's finalize is actually misbehaving here, as it is really
>>> doing a transformation that should be its own module pass, run after
>>> globalopt and friends.
>>>
>>> > I didn't think of what would happen if you put the asm printer in the
>>> same
>>> > passmanager. You're right that it doesn't work, but it's not
>>> immediately
>>> > obvious to me that this is asan's fault, or the user's fault for
>>> putting a
>>> > per-function asm printer inside the same pass manager.
>>>
>>> Forgive my ignorance, but what problem are you envisioning here, and
>>> how can I observe it? I'd like to understand it fully to see in what
>>> ways my thoughts above would or wouldn't interact with it, and I'm
>>> just not sufficiently familiar w/ the asm printer infrastructure...
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121119/649dadda/attachment.html>