similar to: [LLVMdev] MP1: Gelementptr question

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

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,

On Fri, Oct 7, 2011 at 2: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*

​Appreciate all of the quick responses to my ridiculous questions so far. Hoping this one attracts similarly good dis​cussion! Let's say I have the following series of instructions: %a = load i32, i32* %ptr1 %b = load i32, i32* %ptr2 %c = add i32 %a, %b store i32 %c, i32* %ptr3 This gets compiled (roughly) to mov eax, dword ptr [rsp - 4] add eax, dword ptr [rsp - 8] mov dword

Hello, I've run into a problem which is both maddening and rather hard to replicate, therefore I wondered if someone might know of a plausible explanation for it. I couldn't find anything in the archives, though maybe I'm searching for the wrong thing. I'm calling some C code using .C, and get the vector I'm interested in back as the 7th location in the returned list.

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

Hi Danny, Thanks for that :) However I've just updated the prototype patch to NewGVN and it didn't need any API changes - all I rely on is GVNExpression. Hongbin, I wanted to explain a little about what GVNSink can currently do, what it was designed for and hopefully how to make it handle your testcase. *Background* Common code sinking is more difficult to efficently do than one might

Hello again, When I had originally discussed this proposal, it was thought that we would not have to worry about control dependencies on the noalias metadata because such dependencies could only present a problem when 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:

Introduction ============ I'm currently in the middle of what initially looked to be a simple change in GVN but is turning out to have unexpected consequences that are turning out to be quite difficult to resolve, so I thought I'd send out an RFC to make sure that I'm not barking up the wrong tree with how I'm trying to do this. Motivation and current behaviour

Hi, Following is excerpted from dynamic-vector-gep.ll. The resulting "extractelement" seems to always return 0.0f regardless the value idx1 and idx2 is holding. Am I missing something here or there is something fishy take place? Thanks Shuxin 101 ; CHECK: test6 102 ; CHECK: insertelement <4 x float> zeroinitializer, float 1.000000e+00, i32 %idx1 103 ; CHECK:

Hi Shuxin I think i might have written that test. And yeah, no matter what values you get you’ll get a 0.0. Its probably a bad test case, but i can’t remember if it exposed a bug in this form or not. Since writing it Chandler rewrote SROA anyway so the original bug is long gone. Thanks, Pete On Apr 5, 2013, at 11:57 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, > >

Hi Mon Ping, > I don't have a problem having another class, TargetAddrSpace, to store this > information. However, I don't think it make sense being a standalone pass. > Address spaces seems to part of the TargetData and it seems more natural > to ask the TargetData to return the TargetAddrSpace object (similar to > struct layout) to describe the relationships

It seems the same bug is there if we do pointer swapping with selects. Do you agree? (see example below) define void @f() { entry: %a1 = alloca float, align 4 %a2 = alloca float, align 4 br label %loop end: ret void loop: %phi = phi i32 [ 0, %entry ], [ 1, %loop ] %select_cond = icmp eq i32 %phi, 0 %ptr1 = select i1 %select_cond, float* %a1, float* %a2 %ptr2 = select i1

Hello everyone, In December, I had started a thread on scoped no-alias metadata in order to represent C99 'restrict' pointer information at the IR level: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056586.html At this point, we also have another important use case: preserving the existing 'noalias' attributes on pointers after inlining. My original proposal was

On Sep 12, 2007, at 6:41 PM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote: > Chris, > Extending LLVM IR to support PointerTypes that take an address > space is > what I was hoping to avoid. However, if we want to do things right, > that > is probably the way to go. Now that we got here, let me write some > of my >

Hi Matthijs, Sorry for not responding earlier. I have a few comments. On Aug 7, 2008, at 7:41 AM, Matthijs Kooijman wrote: > 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

Thank you Chris and Christopher, I agree... the Embedded C Language Extensions report provides a good foundation to build on, and what it proposes as far as Address Space is probably a super set of what we have in our existing compiler (and probably would like to keep) so no conflict there. I also agree that regardless of how we would like to deal with pointers, the same extensions must be applied

Chris, Extending LLVM IR to support PointerTypes that take an address space is what I was hoping to avoid. However, if we want to do things right, that is probably the way to go. Now that we got here, let me write some of my thoughts on this and solicit your input: --- 1) Syntax extension: In our existing compiler for 8-bit microcontrollers, we have introduced rom and ram qualifiers (with ram

On Thu, 13 Sep 2007 Alireza.Moshtaghi at microchip.com wrote: > I think it all boils down to whether you think it is time to incorporate > these extensions into LLVM IR and how long do you think it will take to > do so? Sure, any time is good. The reason we don't have this now is primarily because noone has stepped up to contribute it. If you're like to start this, I'd be

Alias analysis is figuring out the relationship between two pointer expressions, at some location in the program. At a given point in the program, do two expressions always refer to the same location? At a given point in the program, do two expressions never refer to the same location? AliasAnalysis::alias() doesn't explicitly take a "point" in the program because we don't