search for: destloc

On Nov 6, 2007, at 5:45 PM, Bill Wendling wrote: > Hi all, > > This patch is to fix a problem on PPC64 where an unaligned memcpy is > generated. The testcase is this: > > $ cat testcase.c > void Qux() { > char Bar[11] = {0}; > } > > What happens is that we produce LLVM code like this: > > call void @llvm.memcpy.i64( i8* %event_list2, i8* getelementptr ([11

How about this patch then? -bw Index: gcc/llvm-convert.cpp =================================================================== --- gcc/llvm-convert.cpp (revision 43658) +++ gcc/llvm-convert.cpp (working copy) @@ -758,7 +758,7 @@ } -Value *TreeToLLVM::Emit(tree exp, Value *DestLoc) { +Value *TreeToLLVM::Emit(tree exp, Value *DestLoc, unsigned Alignment) { assert((isAggregateTreeType(TREE_TYPE(exp)) == (DestLoc != 0) || TREE_CODE(exp) == MODIFY_EXPR) && "Didn't pass DestLoc to an aggregate expr, or passed it to scalar!"); @@...

Hi all, This patch is to fix a problem on PPC64 where an unaligned memcpy is generated. The testcase is this: $ cat testcase.c void Qux() { char Bar[11] = {0}; } What happens is that we produce LLVM code like this: call void @llvm.memcpy.i64( i8* %event_list2, i8* getelementptr ([11 x i8]* @C.103.30698, i32 0, i32 0), i64 11, i32 8 ) Notice that it has an 8-byte alignment. However, the Bar

...Changing the alignment of > bar papers over this problem, but we will still get improper alignment > for other cases. Also, DECL_USER_ALIGN isn't appropriate to tweak > here... the user isn't playing around with __attribute__((aligned)) the fundamental problem is that the DestLoc argument to Emit doesn't come with alignment (or volatility for that matter). When emitting an aggregate into DestLoc only the alignment of the source is used, not that of DestLoc. But that's wrong if DestLoc is less aligned than the source (either because the source is highly aligned, eg...

...system to select the correct library. Now the build fails while compiling a code that has __builtin_va_copy. The attached test.i fails with: cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value* TreeToLLVM::Emit(tree_node*, llvm::Value*): Assertion `(isAggregateType(((exp)->common.type)) == (DestLoc != 0) || ((enum tree_code) (exp)->common.code) == MODIFY_EXPR) && "Didn't pass DestLoc to an aggregate expr, or passed it to scalar!"' failed. I know that linux/amd64 is not currently supported, but does someone knows how to fix this? Thanks, Rafael -------------- nex...

...ow the Applied. > build fails while compiling a code that has __builtin_va_copy. The > attached test.i fails with: > > cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value* > TreeToLLVM::Emit(tree_node*, llvm::Value*): Assertion > `(isAggregateType(((exp)->common.type)) == (DestLoc != 0) || ((enum > tree_code) (exp)->common.code) == MODIFY_EXPR) && "Didn't pass DestLoc > to an aggregate expr, or passed it to scalar!"' failed. > > I know that linux/amd64 is not currently supported, but does someone > knows how to fix this? Can you g...

> How about this patch then? How about this one :) It passes alignment and volatility around with DestLoc. It's not finished because I noticed some bugs in how CopyAggregate and ZeroAggregate handle alignment (problem points marked with "QQ"). Also, I noticed potential problems with how we handle call arguments and return results (what if they are strangely aligned/volatile?), marked wi...

...Will it break the world? -bw Index: gcc/llvm-convert.cpp =================================================================== --- gcc/llvm-convert.cpp (revision 43366) +++ gcc/llvm-convert.cpp (working copy) @@ -3020,8 +3020,26 @@ Emit(TREE_OPERAND(exp, 1), LV.Ptr); EmitAggregateCopy(DestLoc, LV.Ptr, TREE_TYPE(exp), isVolatile, false, Alignment); } else if (!isVolatile && TREE_CODE(TREE_OPERAND(exp, 0))!=RESULT_DECL) { - Emit(TREE_OPERAND(exp, 1), LV.Ptr); + // At this point, Alignment is the alignment of the destination + // pointer....

...vert.cpp:4083 #5 0x0028b624 in emit_global_to_llvm (decl=0x45e4c700) at ../../src/gcc/llvm-backend.cpp:377 #6 0x00284844 in rest_of_decl_compilation (decl=0x45e4c700, top_level=0, at_end=0) at ../../src/gcc/passes.c:252 #7 0x002a7da8 in TreeToLLVM::EmitBIND_EXPR (this=0xbfffe63c, exp=0x45e4d5a0, DestLoc=0x0) at ../../src/gcc/llvm-convert.cpp:1119 #8 0x00297ac0 in TreeToLLVM::Emit (this=0xbfffe63c, exp=0x45e4d5a0, DestLoc=0x0) at ../../src/gcc/llvm-convert.cpp:474 #9 0x002882f0 in llvm_emit_code_for_current_function (fndecl=0x45e4ae00) at ../../src/gcc/llvm-backend.cpp:309 It is compiling libgfo...

...sed asm-frame-size 0 BLK file ../../source/gcc/libgcov.c line 818 size <integer_cst 0x20000820ea0 128> unit size <integer_cst 0x20000820ed0 16>    align 64 context <function_decl 0x20000b08300 __gcov_execl>    LLVM: %struct.va_list* %ap chain <var_decl 0x20000b44300 aq>> DestLoc is 0. Anyone have a suggestion on how to fix this? Thanks, Andrew

On 11/7/07, Duncan Sands <baldrick at free.fr> wrote: > > How about this patch then? > > How about this one :) Your patch didn't apply cleanly, so I couldn't test it out. :-( -bw > It passes alignment and volatility around > with DestLoc. It's not finished because I noticed some bugs in > how CopyAggregate and ZeroAggregate handle alignment (problem points > marked with "QQ"). Also, I noticed potential problems with how we > handle call arguments and return results (what if they are strangely > aligned/v...

...Index: gcc/llvm-convert.cpp > =================================================================== > --- gcc/llvm-convert.cpp (revision 43366) > +++ gcc/llvm-convert.cpp (working copy) > @@ -3020,8 +3020,26 @@ > Emit(TREE_OPERAND(exp, 1), LV.Ptr); > EmitAggregateCopy(DestLoc, LV.Ptr, TREE_TYPE(exp), > isVolatile, false, > Alignment); > } else if (!isVolatile && TREE_CODE(TREE_OPERAND(exp, 0))! > =RESULT_DECL) { > - Emit(TREE_OPERAND(exp, 1), LV.Ptr); > + // At this point, Alignment is the alignment of...