similar to: [LLVMdev] Why does llvm bitcast a struct pointer to an integer pointer?

I have some C code that does a memcpy (though it doesn't use the memcpy instrinsic at all) on structure like: x = y; Where x and y are of the same structure type. My question is in the LLVM code, it firsts get the address from the GEP using the struct type but then before the load and store, it bitcasts this to i64 for some reason? Why does this occur in the IR? Doesn't seem like the

I am using LLVM C++ API to generate IR for some structure data. For example: struct mystruct {int a:1; int b:2; unsigned long c} = {{1, 2, 3}}; I read the document and tried the demo cgi, it seems the API requires user to handle padding and value combination for the initializer by themselves. Is there any way to create the struct more simply like this:

On Thu, Oct 25, 2012 at 3:15 PM, Pranav Bhandarkar <pranavb at codeaurora.org>wrote: > Hi, > > I have the following IR code > > </snippet> > %prev = getelementptr inbounds %struct.myStruct* %node, i32 0, i32 1 > %1 = load %struct.myStruct** %prev, align 4, !tbaa !0 > %next1 = getelementptr inbounds %struct.myStruct* %1, i32 0, i32 0 > store %struct.myStruct*

Hi, I have the following IR code </snippet> %prev = getelementptr inbounds %struct.myStruct* %node, i32 0, i32 1 %1 = load %struct.myStruct** %prev, align 4, !tbaa !0 %next1 = getelementptr inbounds %struct.myStruct* %1, i32 0, i32 0 store %struct.myStruct* %0, %struct.myStruct** %next1, align 4, !tbaa !0 %2 = load %struct.myStruct** %prev, align 4, !tbaa ! </snippet> myStruct is

Hi , The following loop fails to be vectorized since the load c[i] is casted as i64 and the store c[i] is double. The loop access analysis gives up since they are in different types. Since these two memory operations are in the same size, I believe the loop access analysis should return forward dependence and thus the loop can be vectorized. Any comments? Thanks, Jin #define N 1000 double

Instrinsic llvm.memory.barrier does not work as expected. Is it a bug or it has not been implemented yet ? (1) false arguments do not work // pesudo code void foo(int *x) { x[2] = 10; llvm.memory.barrier(0, 0, 0, 0, 0); x[2] = 20; return void } The barrier is actually noop, but it prevents "x[2] = 10" from being deleted. (2) True arguments do not work. // pesudo code

I'm having trouble getting my backend to properly treat the situation where a char* is converted into a struct, i.e. something like: char* pointer_representation = ...; MyStruct* my_struct = (MyStruct*) pointer_representation; my_struct->an_int_field = 5; When this occurs, LLVM seems to fold the struct and char* into one assembly 'object', which is perfectly fine. However, it also

On Fri, Oct 12, 2012 at 10:43 AM, Stephen McGruer <stephen.mcgruer at gmail.com> wrote: > I'm having trouble getting my backend to properly treat the situation where > a char* is converted into a struct, i.e. something like: > > char* pointer_representation = ...; > MyStruct* my_struct = (MyStruct*) pointer_representation; > my_struct->an_int_field = 5; > >

If you could point me towards the correct location in the standard I would appreciate that - I didn't realize it wasn't acceptable to turn pointer-data to structs. My example is reduced from the EEMBC benchmarks where I ran into the problem, so I may have reduced it too far by accident (but I'm fairly sure they do not use __attribute__ or similar). Adding a

Hi All, I have a question on ConstantExpressions and llvm intrinsic memcpy/memset/memmove. I am using llvm-2.8 release. In one of the C programs that I am compiling using clang frontend, the call to memcpy instrinsic looks like the following call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp2, i8* bitcast (%struct.ta* @tret to i8*), i64 4, i32 4, i1 false), !dbg !19 The second argument to memcpy is

On 4/14/11 6:34 PM, Kodakara, Sreekumar V wrote: > > Hi All, > > I have a question on ConstantExpressions and llvm intrinsic > memcpy/memset/memmove. I am using llvm-2.8 release. In one of the C > programs that I am compiling using clang frontend, the call to memcpy > instrinsic looks like the following > > call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp2, i8* bitcast

Dear Developers, I compiled a OpenCL kernel before (on Nov. last year) like __kernel void g(__global float* array) { array[get_global_id(0)] = 1; } with libclc, which would originally use the instrinsics like llvm.r600.read.local.size.x(). I executed the generated object file with one version of the hsa-runtime [1] provided by Mr. Stellard, when there was more than one workgroup, the output

If I understand you correctly, conceptually you want two different objects to be returned for Foo.bl and Foo.al? Here is my take on this (take this with a grain of salt, Dan is the expert on this): http://llvm.org/docs/GetElementPtr.html#what-happens-if-an-array-index-is-out-of-bounds LLVM's semantic allows for arrays to be accessed out of bounds - this allows you to walk from the first

Hi all, One of the reasons the Livermore Loops couldn't be vectorized is that it was using global structures to hold the arrays. Today, I'm investigating why is that so and how to fix it. My investigation brought me to LoopVectorizationLegality::canVectorizeMemory(): if (WriteObjects.count(*it)) { DEBUG(dbgs() << "LV: Found a possible read/write reorder:"

Hi I have some problems in defining new generic functions and classes. Just have a look at the following example: require(fPortfolio) setClass("PROBECLASS", representation( type="character" ) ) isGeneric("setType<-") #Returns TRUE #I would like to define a specific function for

Hi I have some problems in defining new generic functions and classes. Just have a look at the following example: require(fPortfolio) setClass("PROBECLASS", representation( type="character" ) ) isGeneric("setType<-") #Returns TRUE #I would like to define a specific function for

I'm trying to generate the declarations for function intrinsics, and I must be misunderstanding how to create new functions - I saw that a function with no basic blocks is treated as a declaration, so I tried to just create one and add it to the globals list: llvm_type *structTy, *ptrToStructTy; structTy = llvm_type_create_struct(0, 0); structTy =

Hi Xiaoyi, this looks like a bug to me - please file a bug report. Ciao, Duncan. On 01/11/12 04:35, Guo, Xiaoyi wrote: > I have three modules: > ----------------------------------------------------------------- > s1.ll: > > %0 = type <{ i32, i32 }> > > define void @s1(%0* byval %myStruct) nounwind { > return: > ret void > } >

----- Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > If I understand you correctly, conceptually you want two different objects to be returned for Foo.bl and Foo.al? > > Here is my take on this (take this with a grain of salt, Dan is the expert on this): > > http://llvm.org/docs/GetElementPtr.html#what-happens-if-an-array-index-is-out-of-bounds > >

On Mon, 7 Mar 2005, John Carrino wrote: > As far as I can tell, when you construct a type using the support > library StructType::get, you have to pass in a list of types. How can > you make a Recursive type by passing in a pointer to the type you are > constucting. > > An example where something really simple like the line below was output > would be perfect. > >