<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 26, 2018 at 12:29 PM Fedor Sergeev via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 09/26/2018 10:04 PM, David Greene wrote:<br>
 > But they're deeply connected.  I debug codegen problems all the time.<br>
 > That opt-bisect doesn't work with codegen is really unfortunate.<br>
Perhaps I'm missing some context here, but afaik current <br>
-opt-bisect-limit does work with codegen.<br>
And even if you turn on new pass manager and use -opt-bisect-limit you will<br>
still get bisect on codegen (which runs under legacy and thus has legacy <br>
OptBisect<br>
applied there).<br></blockquote><div>One concern for me here is that in legacy optbisect, you will get a continuous counting of passes from IR through codegen, like:</div><div>PASS (1): IR pass no.1</div><div>...</div><div>PASS (n): IR pass no.n</div><div>PASS (n+1): Codegen pass no.1</div><div>...</div><div>PASS (n+m): Codegen pass no.m</div><div><br></div><div>Now with this new design, we need the new opt-bisect from Pass instrumentation (for new PM for IR) together with</div><div>-opt-bisect-limit (for legacy PM for codegen). And they do their own counting separately. It may make bisecting become a little</div><div>bit complex.</div><div><br></div><div>We may want a wrapper above them so that user will not notice the difference from the change.</div><div><br></div><div>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</div><div>be easy since new PM doesn't deal with codegen.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
 > If opt-bisect should work with codegen then we need to think about how<br>
 > codegen will work with the new PM.<br>
Just as it works now - IR passes are run through new PM pipeline, while <br>
Codegen passes<br>
are run through legacy pipeline.<br>
<br>
 > I agree that whether or not the new PM becomes default is somewhat<br>
 > orthogonal but eventually it will and at that point I hope we have a<br>
 > functioning opt-bisect for codegen.<br>
I do expect opt-bisect to be functional for the whole compilation that <br>
involves<br>
new PM at a very first attempt of implementation being discussed here.<br>
Thats why I mentioned the need for "joint implementation" in my original <br>
mail.<br>
<br>
regards,<br>
   Fedor.<br>
<br>
<br>
 ><br>
 >                             -David<br>
 ><br>
 > Fedor Sergeev <<a href="mailto:fedor.sergeev@azul.com" target="_blank">fedor.sergeev@azul.com</a>> writes:<br>
 ><br>
 >> I would really like to separate OptBisect and New-PM-by-default<br>
 >> discussions! :)<br>
 >><br>
 >> regards,<br>
 >>   Fedor.<br>
 >><br>
 >> On 09/26/2018 09:13 PM, David Greene wrote:<br>
 >>> I'm concerned about codegen.  If Codegen is not yet ready for the new<br>
 >>> PM, should the new PM really become default?  I would at least like to<br>
 >>> see a plan of how Codegen is going to migrate before the new PM becomes<br>
 >>> default.  Codegen pass pipelines have been wonky ever since I started<br>
 >>> working with LLVM and it would be nice to get that cleaned up.<br>
 >>><br>
 >>>                              -David<br>
 >>><br>
 >>> Philip Pfaffe <<a href="mailto:philip.pfaffe@gmail.com" target="_blank">philip.pfaffe@gmail.com</a>> writes:<br>
 >>><br>
 >>>> Well, I think we don't have a clear idea about new-PM codegen should<br>
 >>>> work in general. Is this really something that concerns us right now?<br>
 >>>><br>
 >>>> Philip<br>
 >>>><br>
 >>>> On Wed, Sep 26, 2018 at 7:54 PM Friedman, Eli<br>
 >>>> <<a href="mailto:efriedma@codeaurora.org" target="_blank">efriedma@codeaurora.org</a>> wrote:<br>
 >>>><br>
 >>>>      On 9/26/2018 10:47 AM, Philip Pfaffe via llvm-dev wrote:<br>
 >>>>      > Hi Fedor,<br>
 >>>>      ><br>
 >>>>      > can you make an example where a pass actually needs to opt-out?<br>
 >>>>      > Because IMO, bisect should quite literally to <br>
DebugCounter-style<br>
 >>>>      skip<br>
 >>>>      > every step in every ::run method's loop. Passes should not even<br>
 >>>>      be<br>
 >>>>      > concerned with this.<br>
 >>>>           This isn't so much an issue for the optimization<br>
 >>>> pipeline, but<br>
 >>>>      code<br>
 >>>>      generation involves some passes which are mandatory (e.g. isel).<br>
 >>>>           -Eli<br>
 >>>>           --<br>
 >>>>      Employee of Qualcomm Innovation Center, Inc.<br>
 >>>>      Qualcomm Innovation Center, Inc. is a member of Code Aurora <br>
Forum,<br>
 >>>>      a Linux Foundation Collaborative Project<br>
 >>>><br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>