[LLVMdev] strict aliasing and LLVM

[Nick Lewycky]

Xinliang David Li wrote:
> As simple as
>
> void foo (int n, double *p, int *q)
> {
>     for (int i = 0; i < n; i++)
>       *p += *q;
> }
>
> clang -O2 -fstrict-aliasing -emit-llvm -o foo.bc -c foo.c
> llc -enable-tbaa -O2 -filetype=asm -o foo.s foo.bc

There's a couple things interacting here:
  * 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.
  * 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.
  * 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.

So, putting that together, one way to do it is:

   clang -O2 -fstrict-aliasing foo.c -flto -c -o foo.bc
   opt -O2 -enable-tbaa foo.bc foo2.bc
   llc -O2 -enable-tbaa foo2.bc -o foo2.s

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.

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".

> Memory accesses remain in the loop.
>
> The following works fine:
>
> void foo(int n, double *restrict p, int * restrict *q)
> {
>    ...
> }
>
> By the way, Is there a performance category in the llvm bug database?

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.

Nick

> Thanks,
>
> David
>
> On Thu, Oct 28, 2010 at 5:59 PM, Dan Gohman <gohman at apple.com
> <mailto:gohman at apple.com>> wrote:
>
>
>     On Oct 28, 2010, at 2:43 PM, Xinliang David Li wrote:
>
>      >
>      >
>      > 2010/10/27 Rafael Espíndola <rafael.espindola at gmail.com
>     <mailto:rafael.espindola at gmail.com>>
>      > 2010/10/27 Xinliang David Li <xinliangli at gmail.com
>     <mailto:xinliangli at gmail.com>>:
>      > > Thanks. Just built clang and saw the meta data and annotations
>     on the memory
>      > > accesses --  is any opt pass consuming the information?
>      >
>      > The tests in test/Analysis/TypeBasedAliasAnalysis suggest that at
>      > least licm is using it. Also note that
>      > lib/Analysis/TypeBasedAliasAnalysis.cpp defines as enable-tbaa option
>      > that is off by default.
>
>     LICM, GVN, and DSE are the major consumers right now. That said, the
>     current TBAA implementation is not very advanced yet.
>
>      > I tried the option -- no much differences in the generated code.
>
>     Can you give an example of code you'd expect to be optimized which
>     isn't?
>
>     Dan
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev