<div dir="ltr">Hey David,<div>I'll take a look at the patch :)</div><div>Sounds like fun work.</div><div><br></div><div>As George says, improving AA significantly will almost always cause significant performance regressions at first, in almost any compiler.</div><div><br></div><div>Compilers knobs, passes, usually get tuned for x amount of freedom, and if you give them 10x, they start moving things too far, vectorizing too much, spilling, etc. </div><div><br></div><div>This was definitely the case for GCC, where adding a precise interprocedural field-sensitive analysis initially regressed performance by a few percent on average.</div><div><br></div><div>I know it was also the case for XLC at IBM, etc.</div><div><br></div><div>Like anything else, just gotta figure out what passes are going nuts, and rework them to have better heuristics/etc.</div><div>The end result is performance improvements, but the path takes a bit of time.</div><div><br></div><div>If you need a way to see whether your analysis has actually done an okay job in the meantime, usually a good way to see if you are doing well or not is to see how many loads/stores get eliminated or moved by various passes before and after.</div><div><br></div><div>If the number is significantly higher, great.</div><div>If the number is significantly lower, something has likely gone wrong :)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 25, 2016 at 8:11 AM, David Callahan via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>(Adding “LLVM Dev”)</div>
<div><br>
</div>
<div>My variant is up as <a href="https://reviews.llvm.org/D23876" target="_blank">https://reviews.llvm.org/<wbr>D23876</a></div>
<div>—david</div>
<div><br>
</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span>George Burgess IV <<a href="mailto:george.burgess.iv@gmail.com" target="_blank">george.burgess.iv@gmail.com</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, August 24, 2016 at 3:17 PM<br>
<span style="font-weight:bold">To: </span>David Callahan <<a href="mailto:dcallahan@fb.com" target="_blank">dcallahan@fb.com</a>><br>
<span style="font-weight:bold">Subject: </span>Re: CFLAA<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">
<div>Hi!</div>
<div><br>
</div>
<div>> I see there is on going work with alias analysis and it appears the prior CFLAA has been abandoned.<br>
</div>
<div><br>
</div>
<div>There was quite a bit of refactoring done, yeah. The original CFLAA is now called CFLSteens, and graph construction was moved to its own bit. We also have CFLAnders, which is based more heavily on the paper by Zheng and Rugina (e.g. no stratifiedsets magic).</div>
<div><br>
</div>
<div>> I have a variant of it where I reworked how compression was done to be less conservative, reworked the interprocedural to do simulated but bounded inlining, and added code to do on-demand testing of CFL paths on both compressed and full graphs.</div>
<div><br>
</div>
<div>Awesome!</div>
<div><br>
</div>
<div>> Happy to share the patch with you if you are interested as well as some data collected</div>
<div><br>
</div>
<div>Yes, please. Would you mind if I CC'ed llvm-dev on this thread (and a few people specifically, who also might find this interesting)?</div>
<div><br>
</div>
<div>> However I was not able to see any performance improvements in the code. In fact on a various benchmarks there were noticeable regressions in measured performance of the generated code. Have you noticed any similar problems?</div>
<div><br>
</div>
<div>I know that a number of people people in the community expressed concerns about how other passes will perform with better AA results (e.g. If LICM becomes more aggressive, register pressure may increase, which may cause us to spill when we haven't before,
etc). So, such a problem isn't unthinkable. :)</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Aug 24, 2016 at 2:56 PM, David Callahan <span dir="ltr">
<<a href="mailto:dcallahan@fb.com" target="_blank">dcallahan@fb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<p class="MsoNormal">Hi Greg,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I see there is on going work with alias analysis and it appears the prior CFLAA has been abandoned.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I have a variant of it where I reworked how compression was done to be less conservative, reworked the interprocedural to do simulated but bounded inlining, and added code to do on-demand testing of CFL paths on both compressed and full
graphs. <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I reached a point where the ahead-of-time compression was linear but still very accurate compared to on-demand path search and there were noticeable improvements in the alias analysis results and impacted transformations. Happy to share
the patch with you if you are interested as well as some data collected.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">However I was not able to see any performance improvements in the code. In fact on a various benchmarks there were noticeable regressions in measured performance of the generated code. Have you noticed any similar problems?<span><font color="#888888"><u></u><u></u></font></span></p>
<span><font color="#888888">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">--david<u></u><u></u></p>
</font></span></div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</span>
</div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">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/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>