[llvm-dev] Porting OptBisect to New Pass Manager

Zhizhou Yang via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 7 18:04:53 PDT 2018


Thanks for bringing this RFC up.

It seems that it will be exactly what we want for opt-bisect in new PM.

I will comment there.

On Wed, Jun 6, 2018 at 5:36 PM Fedor Sergeev via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On 06/07/2018 12:26 AM, Zhizhou Yang via llvm-dev wrote:
> > Hi Chandler,
> >
> > I am now working on a bisecting tool to find mis-optimization on LLVM.
> > I found OptBisect a very useful option and hope to make it work on the
> > new pass manager. I have several questions about it.
> >
> > 1. Any plans to apply codegen stage with new pass manager?
> >     IIUC, new pass manager only works for opt stage. However the
> > OptBisect option tries to accumulate pass counts through opt stage and
> > codegen stage.
> >   Porting it to new pass manager means that, for now opt stage
> > accumulation will use new pass manager and llc stage will still use
> > legacy pass mechanism.
> >   May I ask if there is any plan to apply new pass manager for llc
> > stage? If so, the OptBisect porting will also need to expend to
> > codegen stage in the future.
> >
> > 2.  Do we want optnone support for new pass manager?
> >     I see OptBisect for each pass was first introduced by modifying
> > optnone check. However new pass manager does not support it IIUC.
> >     We can either follow the legacy structure of
> > skipFunction()/Module(), put skippability check in each single pass
> > for new pass manager.
> >     Or since there is no optnone support, we now may also create label
> > on each pass to determine it is skippable or not, and then do the
> > check at pass manager level.
> >
> > 3. No region/basicblock/callgraphscc pass support for new pass manager?
> There is CallGraphSCC pass support in new pass manager.
> See include/llvm/Analysis/CGSCCPassManager.h
>
> There are no plans to implement region/BB passes afaik.
>
> >     In legacy pass manager, OptBisect will be checked by skip()
> > function on certain types of passes. like skipRegion(),
> skipBasicBlocks().
> >     But I did not see implementations of the passes I mentioned above
> > in new passes. So any plan to have them any more?
> >
> > 4. Is PassInfoMixin the right place to put skipPass() function?
> > The OptBisect works like this: At the beginning of each pass runs, it
> > will call a skipFunction()/Module()/... function under pass.h to check
> > if -opt-bisect is set and how much is counter accumulating.
> > Seems all passes come from the structure PassInfoMixin API, and I see
> > name() function in it which is useful of OptBisect.
> > Do you think it is the right place to put the skipPass() function,
> > similar to where skipFunction()/Module() located in legacy pass manager?
> PassInfoMixin was not intended to be a base for hierarchy of Passes, it
> is merely a boilerplate helper.
>
> > I currently have a draft on OptBisect porting implementation, and I am
> > willing to have people review it if you like.
> >
> > Thanks for taking your time on those questions.
> >
> > If anyone is also make similar effort on it, or have any suggestions
> > of implementation, please let me know and I really appreciate :)
> Just (finally! :-/ ) have sent out an RFC exactly on this topic:
>    "RFC: Pass Execution Instrumentation interface"
> It is currently work in progress and rather generic, so feel free to
> comment/put more detail there.
>
> regards,
>    Fedor.
>
> > Best,
> > Zhizhou
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180607/19087a98/attachment.html>


More information about the llvm-dev mailing list