<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 09/26/2018 11:26 PM, Zhizhou Yang wrote:<br>
> One concern for me here is that in legacy optbisect, you will
get a continuous counting of passes from IR through codegen, like:<br>
> PASS (1): IR pass no.1<br>
> ...<br>
> PASS (n): IR pass no.n<br>
> PASS (n+1): Codegen pass no.1<br>
> ...<br>
> PASS (n+m): Codegen pass no.m<br>
><br>
> Now with this new design, we need the new opt-bisect from Pass
instrumentation (for new PM for IR) together with<br>
> -opt-bisect-limit (for legacy PM for codegen). And they do
their own counting separately. It may make bisecting become a little<br>
> bit complex.<br>
><br>
> We may want a wrapper above them so that user will not notice
the difference from the change.<br>
<br>
Thats why I specifically mentioned in my original mail:<br>
----<br>
- since Codegen is still legacy-only we will have to make a joint
implementation that
<br>
provides a sequential passes numbering through both new-PM IR
and legacy Codegen pipelines<br>
----<br>
<br>
There are ways to handle this. Essentially what needs to be done is
to initialize legacy OptBisect with<br>
the final counter produced by new-pm OptBisect.<br>
It does not look like a substantial implementation difficulty.<br>
<br>
regards,<br>
Fedor.<br>
<br>
<div class="moz-cite-prefix">On 09/26/2018 11:26 PM, Zhizhou Yang
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CADePUz-WEjzCswM+V6=HBz2MjfbHzNz4m01Eh0pvN4Mv-WT2eQ@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>