similar to: [LLVMdev] Linker Question

On Oct 5, 2009, at 3:14 PM, David Greene wrote: > When I compile these separately and run llvm-ld -disable-opt I get > this > unfortunate sequence: > > define i32 @main() nounwind { > entry: > %retval = alloca i32 ; <i32*> [#uses=2] > %0 = alloca i32 ; <i32*> [#uses=2] > %"alloca point"

On Monday 05 October 2009 17:21, Chris Lattner wrote: > > Would it break things horribly if I went in and taught > > RecursiveResolveTypes > > how to handle this or would that violate some deep-level assumption? > > This is intentional, but instcombine should clean it up. Are you not > seeing this? If not, instcombine should be improved. The problem is I need to

I have a question about a problem I came across while I was adding support for aggregate va_arg expression in clang. The following is the example program I will use in this email. I compile the program with clang targeting mips. Note that I have not pushed all the changes I have made yet, so you will not be able to see the same results. $ clang -ccc-host-triple mipsel-unknown-linux

Hi Chris, > >> You probably want to somehow extend TargetData to encode the address > >> space descriptions, including pointer sizes and address space > >> relationships. > > Hmm, you have an excellent point there, pointer sizes could indeed easily > > have different sizes in different address spaces... That would make > > TargetData indeed a logical

Hi, I have a doubt with GEP transformation in the instruction-combiner. Consider below test-case: struct ABC { int A; int B[100]; struct XYZ { int X; int Y[100]; } OBJ; }; void Setup(struct ABC *); int foo(int offset) { struct ABC *Ptr = malloc(sizeof(struct ABC)); Setup(Ptr); return Ptr->OBJ.X + Ptr->OBJ.Y[33]; } Generated IR for the test-case: define i32 @foo(i32

Hi, I'm not sure what the expected behavior of calling a bitcasted function is. Suppose you have a case like this (which you get on the source level from attribute alias): @alias_f32 = alias bitcast (i32 (i32)* @func_i32 to float (float)*) define internal i32 @func_i32(i32 %v) noinline nounwind { entry: ret i32 %v } define void @bitcast_alias_scalar(float* noalias %source, float* noalias

On Jul 22, 2008, at 1:36 AM, Matthijs Kooijman wrote: >> Yep, I think it makes sense for TargetData to have info about the >> size/ >> alignment of a pointer in each addr space. That is also easy to >> encode. > Which is an added bonus, but the original subject under discussion > was the > relations between each address space (equivalent, disjoint, subset/

I noticed a strange behavior when a non-prototyped user-defined function is called. E.g. for the following test.c code segment: void foo(void); void bar(void); void foo(void){ bar(); } void bar(void){ printf("inside bar()"); } LLVM-GCC 2.7 -O0 will generate the following code for foo(), which is all fine. define void @foo() nounwind { entry: * call void @bar() nounwind*

On 17 Mar 2015, at 20:06, Junjie Gu <jgu222 at gmail.com> wrote: >> I've just been debugging a related issue with regard to commutativity of address space casts with respect to other operations. One of the optimisers is turning an add after an address space cast into an add before the address space cast. On our architecture, this results in different bounds information being

Hi Chuck, > However, if I comment out the first 2 lines (the prototype declarations), > llvm-gcc will generate the following code for foo() instead: > define void @foo() nounwind { > entry: > %0 = call i32 (...)* bitcast (void ()* @bar to i32 (...)*)() nounwind ; <i32> > [#uses=0] in C a prototype like this void bar() or no prototype at all means that bar takes a

I've got a call instruction: call void bitcast (void (%4 addrspace(1)*, <2 x i32>, <4 x float>)* @_Z12write_imagefPU3AS110_image2d_tDv2_iDv4_f to void (%9 addrspace(1)*, <2 x i32>, <4 x float>)*)(%9 addrspace(1)* %dstimg, <2 x i32> %28, <4 x float> %26) nounwind %4 and %9 are both (stripped) opaque structs. InlineFunction() does not inline this because

If you're able to reproduce the infinite loop with -O3 then you should be able to dump out the IR that causes `opt -instcombine` to infloop, unless the bug is truly esoteric (e.g. only caused by a specific use-list ordering). Maybe take a closer look at the output from `opt -print-before-all -O3`? Alternatively you can use bugpoint to minimize the IR to get a small reproducer that causes

hi, Pete, I understand InstCombine may simplify bitcast to nothing, but the order matters. AlwaysInliner happens in very early stage, and we never call it again. if InstCombine works, can we invoke it before Inliner? thanks, --lx On Mon, Jan 5, 2015 at 5:40 PM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi lx, Philip > > I've seen an instcombine which helps with this

OK, at our end the following workaround seems to be sufficient: // Check if function is called (needs -instcombine pass). Function* callee = call->getCalledFunction(); if (!callee) { // Could be also a function called inside a bitcast. // So try to extract function

Eli, Thanks. I don't think it's a bug in the linker, really… it's required to treat (stripped) opaque types as different, since it really has no way to know if the caller and the callee really are referring to the same thing… though it then seems to turn right around and do exactly that by inserting the bitcast. ;-) (That does come from the linker.) That the linker 'works

Hello, This is an interesting example. Whenever I see strange things like this, I use opt's -lint. In this case, opt -lint reports: Undefined behavior: Call return type mismatches callee return type %call = call float @alias_f32(float %tmp2) #1 You'll get a similar report when the parameter types mismatch. Pete On Wed, May 29, 2013 at 5:40 PM, Arsenault, Matthew <

On Fri, Nov 9, 2012 at 3:25 PM, Relph, Richard <Richard.Relph at amd.com> wrote: > I've got a call instruction: > call void bitcast (void (%4 addrspace(1)*, <2 x i32>, <4 x float>)* @_Z12write_imagefPU3AS110_image2d_tDv2_iDv4_f to void (%9 addrspace(1)*, <2 x i32>, <4 x float>)*)(%9 addrspace(1)* %dstimg, <2 x i32> %28, <4 x float> %26)

Hi there, I'm having trouble getting ExecutionEngine->runStaticConstructorsDestructors(module, true) to actually trigger static destructors in my code. The static constructors however do get called. I don't know if this is an LLVM or Clang issue, from looking at the IR (see below) it looks like the destructor is being tied to cxa_atexit, and I wonder if that is not called by

Hi, i have the following code: define internal %"struct.dexter::ConditionConstant"* @_ZN6dexter18BinaryConditionAdd8evaluateEv5(%"class.dexter::BinaryConditionAdd"*) { entry: %1 = getelementptr inbounds %"class.dexter::BinaryConditionAdd"* %0, i32 0, i32 0, i32 1 %2 = load %"class.dexter::BaseCondition"** %1, align 8 %3 = bitcast

Hi all, I'm looking at following code snippet: void t2(double *x) { long long a[2]; a[0] = 3; a[1] = 5; *x = * ((double *) a); *(x+1) = * ((double *) &a[a[0]-2]); } I use generate LLVM code using my own front-end that looks like: ; ModuleID = 'jb.c' target datalayout =