<br><br><div class="gmail_quote">On Sat, Oct 30, 2010 at 1:44 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;">
Xinliang David Li wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<br>
On Fri, Oct 29, 2010 at 12:26 AM, Nick Lewycky <<a href="mailto:nicholas@mxc.ca" target="_blank">nicholas@mxc.ca</a><br></div><div><div></div><div class="h5">
<mailto:<a href="mailto:nicholas@mxc.ca" target="_blank">nicholas@mxc.ca</a>>> wrote:<br>
<br>
Xinliang David Li wrote:<br>
<br>
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>
<br>
<br>
There's a couple things interacting here:<br>
* clang -fstrict-aliasing -O2 does generate the TBAA info, but it<br>
runs the optimizers without enabling the -enable-tbaa flag, so the<br>
optimizers never look at it. Oops.<br>
* clang -fstrict-aliasing -O0 does *not* generate the TBAA info in<br>
the resulting .bc file. This is probably intended to speed up -O0<br>
builds even if -fstrict-aliasing is set, but is annoying for<br>
debugging what's going on under the hood.<br>
* If clang -O2 worked by running 'opt' and 'llc' under the hood,<br>
we could tell it to pass a flag along to them, but it doesn't. As it<br>
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>
<br>
<br>
-o foo2.bc<br>
<br>
llc -O2 -enable-tbaa foo2.bc -o foo2.s<br>
<br>
at which point the opt run will hoist the loads into a loop<br>
preheader. Sadly this runs the LLVM optimizers twice (once in clang<br>
-O2 and once in opt) which could skew results.<br>
<br>
<br>
Yes, I verified these steps work, but my head is spinning:<br>
<br>
1) does -flto has the same effect as -emit-llvm ? FE emits llvm bitcode<br>
and exit without invoking llvm backend?<br>
</div></div></blockquote>
<br>
Yes, -flto and -emit-llvm are synonyms.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) why do you need to invoke both opt and llc -- I verified invoking<br>
just llc is also fine.<br>
</blockquote>
<br></div>
"llc" is really just codegen; the only optimizations it does are ones that are naturally part of lowering from llvm IR to assembly. For example, that includes another run of loop invariant code motion because some loads may have been added -- such as a load of the GOT pointer -- which weren't there in the IR to be hoisted.<br>
<br>
"opt" runs any IR pass. You can ask run a single optimization, for example "opt -licm" or you can run an analysis pass like scalar evolutions with "opt -analyze -scalar-evolution". This is where the bulk of LLVM's optimizations live.</blockquote>
<div><br></div><div><br></div><div>I thought llc include all standard optimization passes (equivalent to opt -std-compile-opts + machine code generation) --- it seems more natural (to me) to have a single optimization driver that takes llvm bit code as the input. </div>
<div> </div><div><br></div><div>David </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) more general question -- is opt just a barebone llc without invoking<br>
any llvm passes? So why is there a need for two opt driver?<br>
</blockquote>
<br></div>
I think of it as opt transforms .bc -> .bc and llc transforms .bc -> .s.<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>
<br>
I think the right thing to do is to teach the clang driver to remove<br>
-fstrict-aliasing from the cc1 invocation when optimizations are<br>
off. This would let us force the flag through with "-Xclang<br>
-fstrict-aliasing".<br>
<br>
<br>
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<br>
database?<br>
<br>
<br>
Nope, we file bugs based on the type of optimization ought to solve<br>
it (ie., there's a Scalar optimizations category, a Loop optimizer<br>
category, Backend: X86, etc.). Many miscellaneous performance<br>
improvements actually live in lib/Target/README.txt (and subdirs of<br>
there) instead of the bug tracker.<br>
<br>
Nick<br>
<br>
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>
<mailto:<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> <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>
<mailto:<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>><br>
<mailto:<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a><br>
<mailto:<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>>>><br>
<br>
> 2010/10/27 Xinliang David Li <<a href="mailto:xinliangli@gmail.com" target="_blank">xinliangli@gmail.com</a><br>
<mailto:<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> <mailto:<a href="mailto:xinliangli@gmail.com" target="_blank">xinliangli@gmail.com</a>>>>:<div class="im"><br>
<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<br>
enable-tbaa option<br>
> that is off by default.<br>
<br>
LICM, GVN, and DSE are the major consumers right now. That<br>
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<br>
which<br>
isn't?<br>
<br>
Dan<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br></div>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>><div class="im"><br>
<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>
<br>
<br>
<br>
</div></blockquote>
<br>
</blockquote></div><br>