[llvm-dev] OptBisect implementation for new pass manager (original) (raw)

Zhizhou Yang via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 26 13:26:06 PDT 2018

On Wed, Sep 26, 2018 at 12:29 PM Fedor Sergeev via llvm-dev < llvm-dev at lists.llvm.org> wrote:

On 09/26/2018 10:04 PM, David Greene wrote: > But they're deeply connected. I debug codegen problems all the time. > That opt-bisect doesn't work with codegen is really unfortunate. Perhaps I'm missing some context here, but afaik current -opt-bisect-limit does work with codegen. And even if you turn on new pass manager and use -opt-bisect-limit you will still get bisect on codegen (which runs under legacy and thus has legacy OptBisect applied there). One concern for me here is that in legacy optbisect, you will get a continuous counting of passes from IR through codegen, like: PASS (1): IR pass no.1 ... PASS (n): IR pass no.n PASS (n+1): Codegen pass no.1 ... PASS (n+m): Codegen pass no.m

Now with this new design, we need the new opt-bisect from Pass instrumentation (for new PM for IR) together with -opt-bisect-limit (for legacy PM for codegen). And they do their own counting separately. It may make bisecting become a little bit complex.

We may want a wrapper above them so that user will not notice the difference from the change.

I definitely hope there could be one new opt-bisect for new PM that can cover both IR and codegen, but seems it will not be easy since new PM doesn't deal with codegen.

> If opt-bisect should work with codegen then we need to think about how > codegen will work with the new PM. Just as it works now - IR passes are run through new PM pipeline, while Codegen passes are run through legacy pipeline.

> I agree that whether or not the new PM becomes default is somewhat > orthogonal but eventually it will and at that point I hope we have a > functioning opt-bisect for codegen. I do expect opt-bisect to be functional for the whole compilation that involves new PM at a very first attempt of implementation being discussed here. Thats why I mentioned the need for "joint implementation" in my original mail. regards, Fedor.

> > -David > > Fedor Sergeev <fedor.sergeev at azul.com> writes: > >> I would really like to separate OptBisect and New-PM-by-default >> discussions! :) >> >> regards, >> Fedor. >> >> On 09/26/2018 09:13 PM, David Greene wrote: >>> I'm concerned about codegen. If Codegen is not yet ready for the new >>> PM, should the new PM really become default? I would at least like to >>> see a plan of how Codegen is going to migrate before the new PM becomes >>> default. Codegen pass pipelines have been wonky ever since I started >>> working with LLVM and it would be nice to get that cleaned up. >>> >>> -David >>> >>> Philip Pfaffe <philip.pfaffe at gmail.com> writes: >>> >>>> Well, I think we don't have a clear idea about new-PM codegen should >>>> work in general. Is this really something that concerns us right now? >>>> >>>> Philip >>>> >>>> On Wed, Sep 26, 2018 at 7:54 PM Friedman, Eli >>>> <efriedma at codeaurora.org> wrote: >>>> >>>> On 9/26/2018 10:47 AM, Philip Pfaffe via llvm-dev wrote: >>>> > Hi Fedor, >>>> > >>>> > can you make an example where a pass actually needs to opt-out? >>>> > Because IMO, bisect should quite literally to DebugCounter-style >>>> skip >>>> > every step in every ::run method's loop. Passes should not even >>>> be >>>> > concerned with this. >>>> This isn't so much an issue for the optimization >>>> pipeline, but >>>> code >>>> generation involves some passes which are mandatory (e.g. isel). >>>> -Eli >>>> -- >>>> Employee of Qualcomm Innovation Center, Inc. >>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >>>> a Linux Foundation Collaborative Project >>>>

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/20180926/b0f2df1e/attachment.html>

More information about the llvm-dev mailing list