similar to: [LLVMdev] strict aliasing and LLVM

On 27 October 2010 18:17, Xinliang David Li <xinliangli at gmail.com> wrote: > Is type based aliasing implemented in LLVM? Simple test case shows it is > not, or an option similar to -fstrict-aliasing is needed? It is being implemented. You have to use clang, not llvm-gcc. The types are encoded as metadata. Compile with -OX and and look for the TBAA metadata in the .ll file. >

Thanks. Just built clang and saw the meta data and annotations on the memory accesses -- is any opt pass consuming the information? By the way the build instruction in this page http://clang.llvm.org/get_started.html needs to be updated -- it recommends config (with default settings) and build llvm in the source dir -- it leaves some 'sticky' generated files in the source dir leading to

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

On Fri, Oct 29, 2010 at 12:26 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > 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

Xinliang David Li wrote: > > > On Fri, Oct 29, 2010 at 12:26 AM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca>> wrote: > > Xinliang David Li wrote: > > As simple as > > void foo (int n, double *p, int *q) > { > for (int i = 0; i < n; i++) > *p += *q; > } > >

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

On Oct 29, 2010, at 12:26 AM, Nick Lewycky wrote: > 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 > >

On Oct 29, 2010, at 11:35 AM, Xinliang David Li wrote: > Thanks for the -m tip to pass llvm options. Why is it not documented anywhere. See http://clang.llvm.org/docs/UsersManual.html#commandline -mllvm flags are somewhat equivalent to gcc -param options. -mllvm flags are for compiler hackers to play with, and are not stable or documented. Once TBAA is stable and reliable it will be

2010/10/27 Rafael Espíndola <rafael.espindola at gmail.com> > 2010/10/27 Xinliang David Li <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.

On 29.10.2010, at 09:26, Nick Lewycky wrote: > * 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

On Fri, Oct 29, 2010 at 3:54 PM, Chris Lattner <clattner at apple.com> wrote: > On Oct 29, 2010, at 11:35 AM, Xinliang David Li wrote: > > Thanks for the -m tip to pass llvm options. Why is it not documented > anywhere. See http://clang.llvm.org/docs/UsersManual.html#commandline > > > -mllvm flags are somewhat equivalent to gcc -param options. -mllvm flags > are

Thanks for the -m tip to pass llvm options. Why is it not documented anywhere. See http://clang.llvm.org/docs/UsersManual.html#commandline <http://clang.llvm.org/docs/UsersManual.html#commandline>David On Fri, Oct 29, 2010 at 2:17 AM, Benjamin Kramer <benny.kra at googlemail.com>wrote: > > On 29.10.2010, at 09:26, Nick Lewycky wrote: > > > * If clang -O2 worked by

On Oct 28, 2010, at 2:43 PM, Xinliang David Li wrote: > > > 2010/10/27 Rafael Espíndola <rafael.espindola at gmail.com> > 2010/10/27 Xinliang David Li <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

2010/10/27 Xinliang David Li <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

Dan Gohman wrote: > > On Oct 29, 2010, at 12:26 AM, Nick Lewycky wrote: > >> 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

On Sat, Oct 30, 2010 at 1:44 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > Xinliang David Li wrote: > >> >> >> On Fri, Oct 29, 2010 at 12:26 AM, Nick Lewycky <nicholas at mxc.ca >> <mailto:nicholas at mxc.ca>> wrote: >> >> Xinliang David Li wrote: >> >> As simple as >> >> void foo (int n, double

When compiling trunk using gcc 4.1.2 on linux/ppc64, I now see a warning that I don't remember seeing previously: llvm[2]: Compiling InlineSpiller.cpp for Release+Asserts build /src/llvm-trunk-dev/include/llvm/ADT/PointerIntPair.h: In member function ‘const PointerTy* llvm::PointerIntPair<PointerTy, IntBits, IntType, PtrTraits>::getAddrOfPointer() const [with PointerTy = void*, unsigned

(sorry for the wide distribution, but this impacts Clang users quite a bit) It's come up a few times in reviews of CFL-AA (a new alias analysis for LLVM), so I wanted to write down what I think the current state actually is for AA pass ordering, why, and how it should look eventually. I may have some bugs here, so please correct me if I miss anything. And I'd love thoughts about the end

On Jan 17, 2013, at 9:27 PM, Dimitri Tcaciuc <dtcaciuc at gmail.com> wrote: > Hey everyone, > > I'm looking at the following two C functions: > > http://pastebin.com/mYWCj6d8 > > Second one is about 50% slower than the first one because in the second case d->data[i * 3 + {X, Y, Z}] loads are not moved out of the second loop and are computed every time j

On Sun, Aug 20, 2017 at 8:54 AM, Ivan A. Kosarev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Daniel, > > > The problem with the way you are trying to show this is that > > there are many ways to prove no-alias, and TBAA is one of them. > > The reason i stare at dump files and debug info is precisely to > > separate the TBAA portion from the rest.