[llvm-dev] OptBisect implementation for new pass manager

[Fedor Sergeev via llvm-dev]

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).

 > 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
 >>>>