<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 6, 2017 at 7:00 AM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On Wed, Jul 5, 2017 at 3:59 PM, Johan Engelen via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Hi all,<br>
>   I just found an optimization regression regarding simple<br>
> dataflow/constprop analysis:<br>
> <a href="https://godbolt.org/g/Uz8P7t" rel="noreferrer" target="_blank">https://godbolt.org/g/Uz8P7t</a><br>
><br>
> This code<br>
> ```<br>
> int dataflow(int b) {<br>
>   int a;<br>
><br>
>   if (b==4)<br>
>     a = 3*b; // fully optimized when changed to a = 3;<br>
>   else<br>
>     a = 5;<br>
><br>
>   if (a == 4)<br>
>     return 0;<br>
>   else<br>
>     return 1;<br>
> }<br>
> ```<br>
> is no longer optimized to just a "return 1". The regression happened in LLVM<br>
> 3.6 --> 3.7.<br>
><br>
> Is this a known regression? I couldn't find it in the bug tracker (but don't<br>
> really know which keywords to look for...)<br>
><br>
> Kind regards,<br>
>   Johan<br>
><br>
<br>
</div></div>This regressed when SimplifyCFG changed the threshold for PHI nodes<br>
folding from 1 to 2.<br>
<br>
(see lib/Transforms/Utils/<wbr>SimplifyCFG.cpp)<br>
<br>
+PHINodeFoldingThreshold("phi-<wbr>node-folding-threshold", cl::Hidden, cl::init(2),<br>
+   cl::desc("Control the amount of phi node folding to perform<br>
(default = 2)"));<br>
<br>
This could be re-evaluated, maybe, or some other transformation could<br>
catch this case.<br></blockquote><div><br></div><div>I'm sure that adjusting that threshold has many implications, so I don't want to touch that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(e.g. a more powerful range solver could realize that a is always in<br>
the range [5;12]).<br></blockquote><div> </div><div>I seem to have been very "lucky" in finding the non-optimized case. I get fully optimized output when replacing "3*b" with "2*b" or "4*b" or "b+b+b+b" or "3*b-b"... But for "3*b", "b+b+b", and "3*b+6" things go wrong.</div><div>Is there another optimization pass interfering?</div><div><br></div><div>regards,</div><div>  Johan</div><div><br></div><div><br></div></div></div></div>