[llvm-dev] OptBisect implementation for new pass manager
Fedor Sergeev via llvm-dev
llvm-dev at lists.llvm.org
Wed Sep 26 13:39:33 PDT 2018
On 09/26/2018 11:26 PM, Zhizhou Yang wrote:
> 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.
Thats why I specifically mentioned in my original mail:
----
- since Codegen is still legacy-only we will have to make a joint
implementation that
provides a sequential passes numbering through both new-PM IR and
legacy Codegen pipelines
----
There are ways to handle this. Essentially what needs to be done is to
initialize legacy OptBisect with
the final counter produced by new-pm OptBisect.
It does not look like a substantial implementation difficulty.
regards,
Fedor.
On 09/26/2018 11:26 PM, Zhizhou Yang wrote:
>
>
> On Wed, Sep 26, 2018 at 12:29 PM Fedor Sergeev via llvm-dev
> <llvm-dev at lists.llvm.org <mailto: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
> <mailto: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
> <mailto: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 <mailto: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 <mailto: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/c486e210/attachment.html>
More information about the llvm-dev
mailing list