[llvm-dev] LLVM Pass Managers

[Son Tuan VU via llvm-dev]

Hi Chandler,

Can you confirm that there's a bug in *verify-each* mode at opt
-O{0/1/2/3/s/z}?

Son Tuan Vu

On Fri, Apr 20, 2018 at 10:56 PM, Vedant Kumar <vsk at apple.com> wrote:

>
>
> On Apr 20, 2018, at 1:46 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote:
>
> Hi Vedant,
>
> Thanks for your reply. More comments inline.
>
> Son Tuan Vu
>
> On Fri, Apr 20, 2018 at 10:19 PM, Vedant Kumar <vsk at apple.com> wrote:
>
>> Hi,
>>
>> + Chandler, who has a lot more experience with our pass managers.
>>
>> On Apr 20, 2018, at 12:56 PM, Son Tuan VU <sontuan.vu119 at gmail.com>
>> wrote:
>>
>> + Vedant: what do you think about the last point, since Debugify is also
>> related?
>>
>>
>> Could you clarify the question? I'm not sure what it is you'd like me to
>> chime in about.
>>
>> I guess you now know what I wanted to ask?
>
>
> I think there was a little confusion, as I thought the "last point" was
> something Philip had said. I suppose you just meant question #2 from your
> first email.
>
>
>
>> 2, I've asked this question once but have had no answer, so I'm gonna
>> revive it here: in *opt*, the *verify-each* mode is only activated when
>> we provide a pass name or a pipeline (list of pass names).  I guess this is
>> intended, but I expect that *verify-each* to insert *Verifier* to the
>> whole pipeline after each optimization pass, even when I pass -O1/2/3/s/z
>> to *opt*.  And I assume others do expect the same thing.
>>
>>
>> I'd expect the same thing. I'm pretty sure it's a missing feature that
>> -verify-each doesn't apply at opt -O1/etc.
>>
>>
>> The 2nd question lead me to another idea: if we really want to make
>> *verify-each* to work on any pipeline (not only user-provided ones), and
>> we'll soon have a *debugify-each* option, should we refactor the code to
>> have a *apply-after-each=pass-name* option that automatically inserts
>> *pass-name *to the pipeline after each optimization pass?  We can even
>> replace *print-after-all* option with
>> *apply-after-each=PrintModulePassWrapper *for example?
>>
>>
>> Speaking for myself, I'd rather type "opt -foo-each" over "opt
>> -apply-after-each=foo".
>>
>
> I agree that "opt -foo-each" would be easier and more intuitive, but if
> someone ever wants to apply foo after each pass, she will have to hack into
> opt and write her own custom PassManager. Or maybe this situation is not
> likely to happen?
>
>
> This doesn't seem like a common scenario to me.
>
> vedant
>
>
>> best,
>> vedant
>>
>>
>>
>> Son Tuan Vu
>>
>> On Thu, Apr 19, 2018 at 6:14 PM, Philip Pfaffe <philip.pfaffe at gmail.com>
>> wrote:
>>
>>> Hi Son,
>>>
>>> PassManagerBuilder is used to populate legacy PassManagers.  That role
>>> is taken over by PassBuilder for new-PM passes.
>>>
>>> Cheers,
>>> Philip
>>>
>>> 2018-04-18 13:40 GMT+02:00 Son Tuan VU <sontuan.vu119 at gmail.com>:
>>>
>>>> Hi Philip,
>>>>
>>>> Thank you for your reply. So what would be the right way/API to write
>>>> out-of-tree pass? I've been using *PassManagerBuilder*, which requires
>>>> a callback refering to *legacy::PassManagerBase*, so I guess this will
>>>> be no longer the good way to go?
>>>>
>>>> Son Tuan Vu
>>>>
>>>> On Tue, Apr 17, 2018 at 6:06 PM, Philip Pfaffe <philip.pfaffe at gmail.com
>>>> > wrote:
>>>>
>>>>> Hi Son,
>>>>>
>>>>> I have an answer to your first question:
>>>>>
>>>>> 1, What are the differences between *LegacyPassManager* and
>>>>>> *PassManager*?  I see that *opt* uses the former most of the times
>>>>>> while the latter is used via *PassBuilder* API when an user wants to
>>>>>> build her own pipeline, but I have no idea why so. What to use and when to
>>>>>> use it is not clear to me.
>>>>>>
>>>>> PassManager is the result of a long going effort to replace the
>>>>> default pass manager of opt and clang. Here's the original RFC containing
>>>>> the motivation: http://lists.llvm.org/pipermai
>>>>> l/llvm-dev/2012-July/051643.html
>>>>>
>>>>> LegacyPassManager is currently still the default, but we are really
>>>>> close to switching over the the new one. Both opt and clang have switches
>>>>> to enable the new one, by calling `opt -passes="...."` or `clang
>>>>> -fexperimental-new-pass-manager`. PassBuilder is essentially a big
>>>>> factory to produce PassManager and AnalysisManager objects for the passes
>>>>> and analyses included in core LLVM. If you develop analyses and passes, I'd
>>>>> suggest doing so against the new PM, especially if you plan on upstreaming
>>>>> your work.
>>>>>
>>>>> Cheers,
>>>>> Philip
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180423/68386f19/attachment.html>