<br><br><div class="gmail_quote">On Fri, Oct 29, 2010 at 12:26 AM, Nick Lewycky <span dir="ltr"><<a href="mailto:nicholas@mxc.ca">nicholas@mxc.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Xinliang David Li wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As simple as<br>
<br>
void foo (int n, double *p, int *q)<br>
{<br>
for (int i = 0; i < n; i++)<br>
*p += *q;<br>
}<br>
<br>
clang -O2 -fstrict-aliasing -emit-llvm -o foo.bc -c foo.c<br>
llc -enable-tbaa -O2 -filetype=asm -o foo.s foo.bc<br>
</blockquote>
<br></div>
There's a couple things interacting here:<br>
* clang -fstrict-aliasing -O2 does generate the TBAA info, but it runs the optimizers without enabling the -enable-tbaa flag, so the optimizers never look at it. Oops.<br>
* clang -fstrict-aliasing -O0 does *not* generate the TBAA info in the resulting .bc file. This is probably intended to speed up -O0 builds even if -fstrict-aliasing is set, but is annoying for debugging what's going on under the hood.<br>
* If clang -O2 worked by running 'opt' and 'llc' under the hood, we could tell it to pass a flag along to them, but it doesn't. As it stands, you can't turn -enable-tbaa on when running clang.<br>
<br>
So, putting that together, one way to do it is:<br>
<br>
clang -O2 -fstrict-aliasing foo.c -flto -c -o foo.bc<br>
opt -O2 -enable-tbaa foo.bc foo2.bc<br></blockquote><div><br></div><div> -o foo2.bc</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
llc -O2 -enable-tbaa foo2.bc -o foo2.s<br>
<br>
at which point the opt run will hoist the loads into a loop preheader. Sadly this runs the LLVM optimizers twice (once in clang -O2 and once in opt) which could skew results.<br></blockquote><div><br></div><div>Yes, I verified these steps work, but my head is spinning:</div>
<div><br></div><div>1) does -flto has the same effect as -emit-llvm ? FE emits llvm bitcode and exit without invoking llvm backend?</div><div>2) why do you need to invoke both opt and llc -- I verified invoking just llc is also fine.</div>
<div><br></div><div>3) more general question -- is opt just a barebone llc without invoking any llvm passes? So why is there a need for two opt driver?</div><div><br></div><div>Thanks,</div><div><br></div><div>David</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I think the right thing to do is to teach the clang driver to remove -fstrict-aliasing from the cc1 invocation when optimizations are off. This would let us force the flag through with "-Xclang -fstrict-aliasing".<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Memory accesses remain in the loop.<br>
<br>
The following works fine:<br>
<br>
void foo(int n, double *restrict p, int * restrict *q)<br>
{<br>
...<br>
}<br>
<br>
By the way, Is there a performance category in the llvm bug database?<br>
</blockquote>
<br></div>
Nope, we file bugs based on the type of optimization ought to solve it (ie., there's a Scalar optimizations category, a Loop optimizer category, Backend: X86, etc.). Many miscellaneous performance improvements actually live in lib/Target/README.txt (and subdirs of there) instead of the bug tracker.<br>
<br>
Nick<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Thanks,<br>
<br>
David<br>
<br>
On Thu, Oct 28, 2010 at 5:59 PM, Dan Gohman <<a href="mailto:gohman@apple.com" target="_blank">gohman@apple.com</a><br></div><div class="im">
<mailto:<a href="mailto:gohman@apple.com" target="_blank">gohman@apple.com</a>>> wrote:<br>
<br>
<br>
On Oct 28, 2010, at 2:43 PM, Xinliang David Li wrote:<br>
<br>
><br>
><br>
> 2010/10/27 Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a><br></div>
<mailto:<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>>><div class="im"><br>
> 2010/10/27 Xinliang David Li <<a href="mailto:xinliangli@gmail.com" target="_blank">xinliangli@gmail.com</a><br></div>
<mailto:<a href="mailto:xinliangli@gmail.com" target="_blank">xinliangli@gmail.com</a>>>:<div class="im"><br>
> > Thanks. Just built clang and saw the meta data and annotations<br>
on the memory<br>
> > accesses -- is any opt pass consuming the information?<br>
><br>
> The tests in test/Analysis/TypeBasedAliasAnalysis suggest that at<br>
> least licm is using it. Also note that<br>
> lib/Analysis/TypeBasedAliasAnalysis.cpp defines as enable-tbaa option<br>
> that is off by default.<br>
<br>
LICM, GVN, and DSE are the major consumers right now. That said, the<br>
current TBAA implementation is not very advanced yet.<br>
<br>
> I tried the option -- no much differences in the generated code.<br>
<br>
Can you give an example of code you'd expect to be optimized which<br>
isn't?<br>
<br>
Dan<br>
<br>
<br>
<br>
<br></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote>
<br>
</blockquote></div><br>