similar to: [LLVMdev] tbaa

Can you post the source code of your test case? Gan On Fri, Dec 2, 2011 at 1:44 PM, <liyi at cs.toronto.edu> wrote: > Hi, > > Could anyone tell me how exactly do I use "Type Based Alias Analysis"? > > I compiled the C program with Clang, and verified that there is tbaa > metadata in the IR code. > > But then when I use "opt -tbaa input.c.bc

Duncan Sands <baldrick <at> free.fr> writes: > > Hi Yi, > > > Could anyone tell me how exactly do I use "Type Based Alias Analysis"? > > > > I compiled the C program with Clang, and verified that there is tbaa > > metadata in the IR code. > > > > But then when I use "opt -tbaa input.c.bc -aa-eval" to check the results,

> On Dec 5, 2011, at 6:04 PM, Daniel Berlin wrote: >> >> Yet, aa-eval still says otherwise. > > The problem is with aa-eval. It collects all the pointer values in a > function, and then just makes a bunch of raw pointer queries, rather than > considering dereferences. TBAA tags are only attached to dereferences. > So TBAA always has to say MayAlias for every aa-eval

Hi Yi, I didn't get a chance to run your code. But from the debug information you posted about tbaa alias analysis: Alias Set Tracker: 1 alias sets for 7 pointer values. AliasSet[0x207f860, 7] may alias, Mod/Ref Pointers: (i32* %1, 4), (i32* %x, 4), (i32** %p, 8), (i32** %q, 8), (float* %z, 4), (float** %t, 8), (i32* %2, 4) I guess it is because of the way how TBAA alias analysis treats

On Mon, Dec 5, 2011 at 11:08 PM, <liyi at cs.toronto.edu> wrote: >> On Dec 5, 2011, at 6:04 PM, Daniel Berlin wrote: >>> >>> Yet, aa-eval still says otherwise. >> >> The problem is with aa-eval. It collects all the pointer values in a >> function, and then just makes a bunch of raw pointer queries, rather than >> considering dereferences. TBAA

[AMD Official Use Only - Internal Distribution Only] Hi, Following issue is observed with Type Based Alias Analysis(TBAA). ####################################################### struct P { float f1; float f2; float f3[3]; float f4; }; void foo(struct P* p1, struct P* p2) { p1->f2 = 1.2; p2->f1 = 3.7; } int callFoo() { struct P p; foo(&p, &(p.f2)); }

On Mon, Dec 5, 2011 at 6:08 PM, <ggan at codeaurora.org> wrote: > Hi Yi, > > I didn't get a chance to run your code. But from the debug information you > posted about tbaa alias analysis: > > Alias Set Tracker: 1 alias sets for 7 pointer values. >  AliasSet[0x207f860, 7] may alias, Mod/Ref   Pointers: (i32* %1, 4), > (i32* %x, 4), (i32** %p, 8), (i32** %q, 8),

Dan, Thanks for clarifying. This makes perfect sense. Gan >> Makes sense. In that case, it would give the expected answers if >> clang was enhanced to properly deal with similar/dissimilar pointer >> types, instead of giving all pointer types the "everything" tag :) > > No, you've confused pointer types with pointee types. That "any pointer"

[AMD Public Use] Hi Oliver, I get rid of the warnings by explicitly type-casting it to struct*, and still get similar results. ####################################################### struct P { float f1; float f2; float f3[3]; float f4; }; void foo(struct P* p1, struct P* p2) { p1->f2 = 1.2; p2->f1 = 3.7; } int callFoo() { struct P p; foo(&p,

Hi Yi, > Could anyone tell me how exactly do I use "Type Based Alias Analysis"? > > I compiled the C program with Clang, and verified that there is tbaa > metadata in the IR code. > > But then when I use "opt -tbaa input.c.bc -aa-eval" to check the results, > it always gives 100% may aliasing no matter what input. you need to run some optimizations on

On Mon, Dec 5, 2011 at 11:01 PM, Dan Gohman <gohman at apple.com> wrote: > On Dec 5, 2011, at 6:04 PM, Daniel Berlin wrote: >> >> Yet, aa-eval still says otherwise. > > The problem is with aa-eval. It collects all the pointer values in a > function, and then just makes a bunch of raw pointer queries, rather than > considering dereferences. TBAA tags are only

On Dec 5, 2011, at 9:32 PM, Daniel Berlin wrote: > On Mon, Dec 5, 2011 at 11:01 PM, Dan Gohman <gohman at apple.com> wrote: >> On Dec 5, 2011, at 6:04 PM, Daniel Berlin wrote: >>> >>> Yet, aa-eval still says otherwise. >> >> The problem is with aa-eval. It collects all the pointer values in a >> function, and then just makes a bunch of raw

Hi, I'm trying to work with Type Based Alias Analysis (TBAA). Here's the example program I'm working with: ;;;;;;;;;;;;;;;;;;;;;; define void @foo(i64* %a, i64* %b, i64 %x, i64 %y) { store i64 %x, i64* %a, !tbaa !2 ; write to stack store i64 %y, i64* %b, !tbaa !3 ; write to heap ret void } !1 = !{!"root"} !2 = !{!"stack", !1} !3 = !{!"heap", !1}

Hello, I am performing alias analysis toward the following simple code: struct MyStruct { int * f1; int * f2; }; void NOALIAS(void* p, void* q){ } int main() { struct MyStruct s[2]; int a,b; s[0].f1 = &a; s[1].f1 = &b; NOALIAS(s[a].f1, s[b].f2); return 0; } When I use the following command to generate .bc code and conduct alias analysis: clang -c -emit-llvm t.c -O2 opt -basicaa

Hey Matt, That's awesome. Thank you very much for all the information and clarification! Just a few follow up questions. Could you kindly shed some lights on it? Thank you! 1. I tried to tweak the code in the following way: - Clang [-> LLVM-IR]: https://llvm.godbolt.org/z/n9rGrs - [LLVM-IR ->] opt: https://llvm.godbolt.org/z/Uc6h5Y And i note that the outputs are: Alias sets for

On Dec 5, 2011, at 6:04 PM, Daniel Berlin wrote: > > Yet, aa-eval still says otherwise. The problem is with aa-eval. It collects all the pointer values in a function, and then just makes a bunch of raw pointer queries, rather than considering dereferences. TBAA tags are only attached to dereferences. So TBAA always has to say MayAlias for every aa-eval query. Dan

> Yes.  The current TBAA implementation is conservative, with the idea that it > can become more aggressive (and with TBAA, this fundamentally means > "more dangerous") with incremental steps. Dan, Could you disclose more details about how to implement the "incremental steps" to handle more complicated alias cases? For example, differentiate different pointers that

Hi, I met an alias analysis problem in the LICM phase. I am using the following piece of code to present this problem. 1 int size; 2 int ** AAA; 3 void * xalloc(int); 4 5 void foo(void) 6 { 7 int i; 8 AAA = (int**) xalloc(size * sizeof(int*)); 9 10 for (i=0; i<size; i++) 11 AAA[i] = 0; 12 } This code tries to

Hello All, I have a question about a May-alias case. Let's look at one simple C example. char *buf[4]; char c; void test(int idx) {   char *a = buf[3 - idx];   char *b = buf[idx];   *a = *b;   c++;   *a = *b; } We can imagine the second "*a = *b" could be removed. Let's look at the IR snippet with -O3 for above example.   1 define void @test(i32 %idx) {   2 entry:  

On Thu, Nov 8, 2012 at 6:53 PM, Pranav Bhandarkar <pranavb at codeaurora.org> wrote: > Hi, > > I am observing some incorrect behavior in basicaa, wherein two pointers that > basicaa should determine to be MustAlias are ending up NoAlias - the other > extreme :( > I am blaming this on basicaa not handling inttoptr. Here is the relevant IR > snippet. >