search for: ptr2

Hi all, I'm having trouble understanding how llvm determines if pointers alias. Consider the following two functions that each do a redundant load: define float @A(float * noalias %ptr1) {   %ptr2 = getelementptr float* %ptr1, i32 1024   %val1a = load float* %ptr1   store float %val1a, float* %ptr2   %val1b = load float* %ptr1   ret float %val1b } define float @B(float * noalias %ptr1, float * noalias %ptr2) {   %val1a = load float* %ptr1   store float %val1a, float* %ptr2   %val1b = load...

...:15 PM, andrew adams <andrew.b.adams at gmail.com> wrote: > Hi all, > > I'm having trouble understanding how llvm determines if pointers > alias. Consider the following two functions that each do a redundant > load: > > define float @A(float * noalias %ptr1) { >   %ptr2 = getelementptr float* %ptr1, i32 1024 >   %val1a = load float* %ptr1 >   store float %val1a, float* %ptr2 >   %val1b = load float* %ptr1 >   ret float %val1b > } > > > define float @B(float * noalias %ptr1, float * noalias %ptr2) { >   %val1a = load float* %ptr1 >   s...

The following is legal LLVM code in which ptr, ptr2, and ptr3 are all aliases: %struct = type { int, int } implementation int %p() { %ptr1 = alloca %struct %ptr2 = getelementptr %struct* %ptr1 %ptr3 = getelementptr %struct* %ptr2, uint 0 %pint = getelementptr %struct* %ptr3, uint 0, ubyte 0 %rval = load int* %pint ret int %rval } Sho...

...have not found anything untoward. Any suggestions would be much appreciated! Regards, Robin # THESE COMMANDS GIVE ONE ANSWER # [the correct answer always begins with 1, the incorrect with -1] > .C("oneMargin", c(1L,1L,1L,1L,1L), c(1L,1L,1L,1L,1L), 1L, c(2L,2L,2L,2L,2L), 5L, ptr1, ptr2)[[7]] [1] 1 -1 -1 1 -1 1 1 -1 -1 1 1 -1 1 -1 -1 1 -1 1 1 -1 1 -1 -1 1 1 -1 -1 1 -1 1 1 -1 > dput(.C("oneMargin", c(1L,1L,1L,1L,1L), c(1L,1L,1L,1L,1L), 1L, c(2L,2L,2L,2L,2L), 5L, ptr1, ptr2)[[7]]) c(1L, -1L, -1L, 1L, -1L, 1L, 1L, -1L, -1L, 1L, 1L, -1L, 1L, -1L, -1L, 1L,...

...I was thinking of type trees that encoded fields giving more guarantees than LLVM IR currently conveys. Admittedly, I have not though this through, whether this could even remotely work for C. > > In LLVM IR: > > struct { int A[100]; int B[100]} S; > > ptr = gep S, 0, 0, x > ptr2 = gep S, 0, 1, y > > = load ptr, !tbaa !"structS::A" > = load ptr2, !tbaa !"structS::B" > > using this you could tell that ptr and ptr2 do not alias without knowing about x and y. > > > you've basically just pushed the problem off into the fronten...

...tly. > This means that ideally we would want to be able to handle copies of the > value stored in some temporary and track it all the way through to it use. > InstCombine will not handle this case, e.g, address space 1 is a subset of 2 > int<1>* ptr = ... > int<2>* ptr2 = ptr1+4 > *ptr2 = ... Won't this code produce a bitcast in the IR, which can be propagated? My current patch doesn't do this, but it should be easy to extend it to also propagate a bitcast past pointer arithmetic. Ie, it should change %tmp = bitcast i32 addrspace(1)* %ptr1 to i32 a...

quite some speed improvement indeed. attached the updated patch to apply to svn/trunk. j -------------- next part -------------- A non-text attachment was scrubbed... Name: theora-mmx.patch.gz Type: application/x-gzip Size: 8648 bytes Desc: not available Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20040824/5a5f2731/theora-mmx.patch-0001.bin

...ields giving more guarantees >> than LLVM IR currently conveys. Admittedly, I have not though this through, >> whether this could even remotely work for C. >> >> In LLVM IR: >> >> struct { int A[100]; int B[100]} S; >> >> ptr = gep S, 0, 0, x >> ptr2 = gep S, 0, 1, y >> >> = load ptr, !tbaa !"structS::A" >> = load ptr2, !tbaa !"structS::B" >> >> using this you could tell that ptr and ptr2 do not alias without knowing >> about x and y. > > > > you've basically just pushed th...

...entry %a = load i32, i32* %A, align 4 %b = load i32, i32* %B, align 4 %mul = mul nsw i32 %b, %a %add.ptr = getelementptr inbounds i8, i8* %arr, i32 %mul br label %for.body for.body: ; preds = %for.body, %for.body.preheader %q.012 = phi i8* [ %add.ptr2, %for.body ], [ %add.ptr, %for.body.preheader ] %i.011 = phi i32 [ %inc, %for.body ], [ 0, %for.body.preheader ] %conv = trunc i32 %i.011 to i8 store i8 %conv, i8* %q.012, align 1 %add.ptr2 = getelementptr inbounds i8, i8* %q.012, i32 %b %inc = add nuw nsw i32 %i.011, 1 %exitcond = icmp...

...mation to its use. This means that ideally we would want to be able to handle copies of the value stored in some temporary and track it all the way through to it use. InstCombine will not handle this case, e.g, address space 1 is a subset of 2 int<1>* ptr = ... int<2>* ptr2 = ptr1+4 *ptr2 = ... InstCombine will not cleanup this case though a copy propagation phase could clean this up. -- Mon Ping -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080809/fc23945f/attachment....

----Snip-- struct st1{ int a; }; struct st2{ int b; }; struct st { struct st1 obj1; struct st2 obj2; }Obj; int test1(struct st1 * ptr1 , struct st2 * ptr2, struct st2 *ptr3) { ptr1->a = 10; *ptr3 = *ptr2; return ptr1->a; } --Snip--- For the above case GCC is able to store forward the value 10 to the return place. LLVM is not doing this. GCC https://godbolt.org/z/FCjCXy LLVM https://godbolt.org/z/TFgnig My understanding is that under str...

...ode was a song that i converted to the vorbis format (Gorillaz - Cling Eastwood) pcmData is defined like this: char pcmData[4096]; the ogg file and the directsound buffer (lpdsBuffer and vorbisFile) have already been set up properly. // code start void PlaybackThread(void *param) { UCHAR *ptr1, *ptr2; DWORD len1, len2; long retVal; int bytes_to_read = 4096; int writeCursor = 0; int bufferReadCursor = 0; bool begPlay = true; int len1_copy, len2_copy; HWND hDlg = (HWND)param; while (!eof) { if (bufferReadCursor > 4096) { // fill more data into the buffer; bytes_to_read = 4...

...asing violations. I looked at the first, and I couldn't tell why gcc (4.3.4) thinks it is wrong: safecode/runtime/BitmapPoolAllocator/PoolAllocatorBitMask.cpp:185: warning: dereferencing type-punned pointer will break strict-aliasing rules Line 185 is: PS->addToList((PoolSlab**)&Pool->Ptr2); and Ptr2 is a field of type void*. Isn't void* compatible with anything? Best regards, --Edwin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091116/f78c1992/attachmen...

...loads or stores are merged (RAUW is called), and transformations should drop metadata when that happens. Now I'm worried that this is not true. Here's a simple example: entry: %x1 = load %ptr1 // loading from ptr here to make all subsequent loads of %ptr safe to speculate %x2 = load %ptr2 ... somewhere: ... call i_may_throw() %y = load %ptr1, !alias.scope !{ !s1 } ... %z = store %ptr2, !alias.scope !{ !s1 }, !noalias !{ !s1 } So now some well-meaning pass swaps the order of the call and the load (legal because it is legal to speculate the load): somewhere: ... %y...

Hi Mon Ping, I've again attached a patch, wich lets LLVM know about about the relations between different address spaces. Instead of cramming this info in with TargetData (with all kinds of unwanted side effects, especially for the IR), I opted to create a new pass, TargetAddrspaces, which holds this information. Just like TargetData, this can be added to the passmanager by the tool running

...o tag all loads and stores in some scope with the scope metadata, and then additionally tag the 'noalias' loads and stores that don't alias with the various loads and stores in that scope (not just with the other noalias loads and stores). = load %ptr1, !alias.scope !scope1 = load %ptr2, !alias.scope !scope1, !noalias !scope1 Generally, when BasicAA is evaluating an aliasing query, if one of the instructions is associated with an alias.scope id that is identical to the noalias scope associated with the other instruction, or is a descendant (in the scope hierarchy) of the noalias...

...t to be able to handle copies >> of the >> value stored in some temporary and track it all the way through to >> it use. >> InstCombine will not handle this case, e.g, address space 1 is a >> subset of 2 >> int<1>* ptr = ... >> int<2>* ptr2 = ptr1+4 >> *ptr2 = ... > Won't this code produce a bitcast in the IR, which can be > propagated? My > current patch doesn't do this, but it should be easy to extend it to > also > propagate a bitcast past pointer arithmetic. > > Ie, it should change > &g...

...#39;t have this crash. 114 define float @test6(i32 %idx1, i32 %idx2) { 115 entry: 116 %0 = alloca %vector.pair 117 store %vector.pair zeroinitializer, %vector.pair* %0 118 %ptr1 = getelementptr %vector.pair* %0, i32 0, i32 0, i32 0, i32 0, i32 %idx1 119 store float 1.0, float* %ptr1 120 %ptr2 = getelementptr %vector.pair* %0, i32 0, i32 1, i32 0, i32 0, i32 %idx2 121 %ret = load float* %ptr2 122 ret float %ret 123 }

...looked at the first, and > I couldn't tell why gcc (4.3.4) thinks it is wrong: > safecode/runtime/BitmapPoolAllocator/PoolAllocatorBitMask.cpp:185: > warning: dereferencing type-punned pointer will break strict-aliasing rules > Line 185 is: PS->addToList((PoolSlab**)&Pool->Ptr2); > > and Ptr2 is a field of type void*. Isn't void* compatible with anything? > No. void* is _convertible_ to an arbitrary pointer type (6.3.2.3p1): A pointer to void may be converted to or from a pointer to any incomplete or object type. A pointer to any incomplete or object...

...n assume the bitcast instruction in LLVM IR has the same definition, does > this mean that the following instruction > > %dst = bitcast i32 %src to v2i16 > > is equivalent to the following sequence of instructions (which I think is lossless)? > > store i32 %src, i32* %ptr > %ptr2 = bitcast i32* %ptr to v2i16* > %dst = load v2i16* %ptr2 while there has been some discussion about changing the definition of bitcast, yes, this is currently the definition. That canLoslesslyBitCastTo returns false for bitcast of i32 to <2 x i16> is probably just an oversight. Please f...