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?> > 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?> > 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/20180420/fc18d622/attachment.html>
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/pipermail/llvm-dev/2012-July/051643.html <http://lists.llvm.org/pipermail/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/20180420/dee515c8/attachment.html>
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>