<div dir="ltr"><div>Thanks for running CFLAA and sharing the numbers :)</div><div><br></div><div>FWIW, when I measured CFLAA bootstrapping clang/LLVM at the end of my internship, the rough numbers were*:<br></div><div>Regular alias stack (BasicAA/...), no CFLAA: ~80% NoAlias responses</div><div>CFLAA only: ~20-25% NoAlias responses</div><div>CFLAA behind the regular alias stack: ~82% NoAlias responses.</div><div><br></div><div>So, CFLAA did help accuracy a bit.</div><div><br></div><div>With this in mind, I'd like to note that there's <i>tons</i> of low-hanging fruit in CFLAA. For instance, we currently treat things like malloc as opaque function calls, rather than as memory allocation functions. Additionally, due to fun corner cases, we do super-conservative things like treating 'a' and 'b' as aliases below:</div><div><br></div><div>int a[10], b[10];</div><div>int N = getN();</div><div>a[N] = 1;</div><div>b[N] = 2;</div><div><br></div><div>...Because we end up emitting two GEPs that use N. I'm not arguing that this is sane behavior, nor am I saying that it's a fundamental problem with CFLAA; it's just that CFLAA is currently very bare-bones, and very little time has been spent making it less so. Hopefully, by the end of this GSoC project, CFLAA will be much fancier, and will give significantly better results. :)</div><div><br></div><div>* - These numbers were taken by throwing logging code into the AA infrastructure. So, "N% NoAlias responses" means that N% of all alias queries issued throughout compilation were answered with NoAlias. The numbers were scraped from the logs that I got from running `ninja clean; ninja check-all` for a release+asserts build of llvm/clang/compiler-rt. Also, these numbers are purely from my memory of mid-2014. So, they may be different now.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 19, 2016 at 12:22 PM, Jia Chen 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">Hi Geoff,<br>
<br>
Thank you so much for the effort!<br>
<br>
It's good to hear that cfl-aa didn't break anything. However, the fact that it doesn't quite affect code generation is also concerning. I'll definitely look into the issue.<div><div><br>
<br>
On 05/19/2016 02:03 PM, Geoff Berry wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Jia,<br>
<br>
We did some testing with CFL-AA enabled on an aarch64 OoO target on the<br>
llvm test-suite and SPEC (with and without LTO).  We didn't observe any<br>
correctness issues.  We didn't really observe any positive or negative<br>
performance differences, other than a single llvm test<br>
llvm-test-suite/SingleSource/Benchmarks/Shootout/lists that improved<br>
~3%.  I also looked over some of the generated code differences: only a<br>
handful of tests changed at all (9 in llvm test-suite, 5 in SPEC2006),<br>
and in most of these only a few functions changed, usually with a small<br>
amount of static instruction differences.  We didn't collect any compile<br>
time data.<br>
<br>
-Geoff<br>
<br>
On 5/16/2016 5:19 PM, Jia Chen via llvm-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello everyone,<br>
<br>
If you've read through my previous introduction email<br>
(<a href="http://lists.llvm.org/pipermail/llvm-dev/2016-May/099573.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2016-May/099573.html</a>), you<br>
can safely ignore this message.<br>
<br>
The short story is: CFL-AA does not seem to be broken anymore. Please<br>
try it out and help us find more bugs / performance issues if<br>
switching to it in the future sounds interesting to you.<br>
<br>
Here are more backgrounds: I was working on a GSoC project, whose<br>
first step is to fix cfl-aa. After a bug was patched up in r268269,<br>
bootstrapping llvm+clang with standalone cfl-aa as well as<br>
cfl-aa+basicaa breaks nothing in llvm test-suite. It shows that cfl-aa<br>
is in a pretty good shape today and are almost ready to be turned out<br>
by default. But before we can do this, we'd like to gather enough<br>
evidences that it is a safe move. A more thorough description of the<br>
current status can be found in the link provided at the beginning of<br>
this message.<br>
<br>
To compile your codes with cfl-aa turned on, simply add " -mllvm<br>
-use-cfl-aa -mllvm -use-cfl-aa-in-codegen" option to the clang command<br>
line arguments.<br>
--<br>
Best Regards,<br>
<br>
--<br>
Jia Chen<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>
<br>
--<br>
Geoff Berry<br>
Employee of Qualcomm Innovation Center, Inc.<br>
  Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<br>
<br>
</blockquote>
<br>
-- <br>
Best Regards,<br>
<br>
--<br>
Jia Chen<br></div></div>
Department of Computer Science<br>
University of Texas at Austin<br>
<a href="mailto:jchen@cs.utexas.edu" target="_blank">jchen@cs.utexas.edu</a><div><div><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>
</div></div></blockquote></div><br></div></div>