llvm dev - Sep 2018 - OptBisect implementation for new pass manager

But they're deeply connected.  I debug codegen problems all the time.
That opt-bisect doesn't work with codegen is really unfortunate.

If opt-bisect should work with codegen then we need to think about how
codegen will work with the new PM.

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.

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

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

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>