similar to: Finding which registers the operand of a load maps to

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 } Should our pass a) ignore this, not replace %ptr1,

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

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

Has anyone had experience using ov_read in a thread with streaming directsound buffers? i have tried the following, but it just produces a repeating garbage noise. i would appreciate some help. notes: test.ogg in my code 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

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*

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,

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.

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:

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

[This mail is a bit long: sorry.] Hi, I have been trying to compile vorbis-tools-1.0beta4 on NetBSD-1.5/i386, and I get the following: --------------------- Upon typing ./configure --prefix=/usr/pkg/ --with-ogg-prefix=/usr/pkg/ --with-vorbis-prefix=/usr/pkg/ --with-ao-prefix=/usr/pkg/ checking for Ogg... yes checking for Vorbis... yes checking for ao... no *** Could not run

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

Robin Getz a ?crit : >> As I told you, bank is a reserved keyword in Analog Devices compiler for >> Blackfin architecture. > > This seems lame, and maybe you need to change the header files inside VDSP++. > (This is pretty common for VDSP users to do when name space clashes occur > with open source software). > > Poking at the VDSP docs, says that it uses bank()

Hi Matthijs, On Aug 11, 2008, at 4:09 AM, Matthijs Kooijman wrote: > >> 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

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 >

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

Hi! Does anyone know how it should be interpreted when one MI has multiple MachineMemOperands? (I've tried to find information but could not find any clear definition.) For example BranchFolder may do things like this (also see https://godbolt.org/z/iphFH4): # *** IR Dump Before Control Flow Optimizer ***: bb.0.entry: ... JCC_1 %bb.2, 5, implicit killed $eflags JMP_1 %bb.1 bb.1.s1:

Hi all -- first time poster, hoping that this is going to the right list. Also a complete LLVM newbie, so please correct any glaring errors in my understanding. I am an architecture researcher at Penn State working on Processing in Memory (PIM) architectures. Currently, I plan to use LLVM to detect and replace groups of instructions which can be accelerated in memory. Once a group of

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

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