similar to: [LLVMdev] Good reference papers for the TypeBasedAliasAnalysis pass

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

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

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

On Mon, Aug 12, 2013 at 6:03 AM, Michele Scandale < michele.scandale at gmail.com> wrote: > On 08/12/2013 12:44 AM, Michele Scandale wrote: > > The idea is to extend the BasicAliasAnalysis to use addrspace modifier + > target > > information to decide aliasing based on physical address spaces and > create a > > "MemorySpaceAliasAnalysis" for those case

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

Hi Duncan, I am hoping to remove the support for the old TBAA format soon. You should be able to switch to the new format by replacing MDNode *AliasTag = MDHelper.createTBAANode(TreeName, getTBAARoot()); with MDNode *AliasType = MDHelper.createTBAAScalarTypeNode(TreeName, getTBAARoot()); MDNode *AliasTag = MDHelper.createTBAAStructTagNode(AliasType, AliasType, 0) Also replacing

On 08/12/2013 02:02 PM, Justin Holewinski wrote: > On Mon, Aug 12, 2013 at 6:03 AM, Michele Scandale <michele.scandale at gmail.com > <mailto:michele.scandale at gmail.com>> wrote: > > On 08/12/2013 12:44 AM, Michele Scandale wrote: > > The idea is to extend the BasicAliasAnalysis to use addrspace modifier + > target > > information to decide

On Mon, Aug 12, 2013 at 8:24 AM, Michele Scandale < michele.scandale at gmail.com> wrote: > On 08/12/2013 02:02 PM, Justin Holewinski wrote: > > On Mon, Aug 12, 2013 at 6:03 AM, Michele Scandale < > michele.scandale at gmail.com > > <mailto:michele.scandale at gmail.com>> wrote: > > > > On 08/12/2013 12:44 AM, Michele Scandale wrote: > >

I was trying to add some stronger assertions in the verifier around !tbaa metadata when I ran into an ambiguity: I think the encoding of the metadata nodes are such that a given node can be interpreted as either a struct type node or a scalar tbaa node. I'd like a sanity check before I try to fix or work around this. Consider some IR that I got from running clang over a small C++ program:

Hi Ivan, The code that we have is indeed different from what the 'standard llvm' expects. Let me explain: in our version we came into this situation in two steps: 1) I added support for 'special types' that map directly to types supported by hardware. These types are represented by a struct containing a single iXXX member, providing the necessary bits of the type, and at the

Hi Manman, thanks for the heads up. I looked into what it would take to produce full struct TBAA metadata from the GCC aliasing info (GCC has aliasing info for struct types, in fact for any type), but it looks kind of tricky. The problem is the "offset" field, which doesn't exist in GCC. In GCC the aliasing information forms a DAG, with a node for each type, plus a special root

On 08/12/2013 02:34 PM, Justin Holewinski wrote: > On Mon, Aug 12, 2013 at 8:24 AM, Michele Scandale <michele.scandale at gmail.com > <mailto:michele.scandale at gmail.com>> wrote: > > On 08/12/2013 02:02 PM, Justin Holewinski wrote: > > On Mon, Aug 12, 2013 at 6:03 AM, Michele Scandale > <michele.scandale at gmail.com <mailto:michele.scandale at

Hi, In lib/Transforms/IPO/PassManagerBuilder.cpp: addInitialAliasAnalysisPasses, I see this code ------ // Add TypeBasedAliasAnalysis before BasicAliasAnalysis so that // BasicAliasAnalysis wins if they disagree. This is intended to help // support "obvious" type-punning idioms. PM.add(createTypeBasedAliasAnalysisPass()); PM.add(createBasicAliasAnalysisPass()); } ------ My

Daniel, Hal, I'm trying to figure out what we would need to do in terms of the current approach, accepting its limitations, to support unions, member arrays, aggregate accesses and type identifiers and what I get looks suspiciously simple. Can you please check it out and let me know if I'm missing something? For unions: TBAA, regardless of a specific approach, cannot guarantee

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

On 08/12/2013 12:44 AM, Michele Scandale wrote: > The idea is to extend the BasicAliasAnalysis to use addrspace modifier + target > information to decide aliasing based on physical address spaces and create a > "MemorySpaceAliasAnalysis" for those case where source language level > information may help, right? I was looking to the AliasAnalysis infrastructure and TBAA

Hi, I have a question about the current definition of TBAA (See [1]). In the LLVM-IR code that we produce, we generate load/stores of struct types. (See [2] and [3] for a godbolt example showing the issue) For following c-alike code: struct S { int dummy; short e, f; } x,y; struct S* p = &x; int foobar() { x.f=42; *p=y; //**** struct copy return x.f; } We produce: