[llvm-dev] OptBisect implementation for new pass manager

[Zhizhou Yang via llvm-dev]

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>