search for: emitaggregatecopy

Displaying 14 results from an estimated 14 matches for "emitaggregatecopy".

2007 Oct 26
2
[LLVMdev] RFC: llvm-convert.cpp Patch
...his a good thing? 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 + //...
2007 Nov 07
3
[LLVMdev] RFC: llvm-convert.cpp Patch
...*Ptr = CastToType(Instruction::BitCast, LV.Ptr, PointerType::get(Ty)); LoadInst *LI = Builder.CreateLoad(Ptr, isVolatile, "tmp"); - LI->setAlignment(Alignment); + LI->setAlignment(DstAlign); return LI; } else { EmitAggregateCopy(DestLoc, LV.Ptr, TREE_TYPE(exp), false, isVolatile, - Alignment); + std::min(DstAlign, SrcAlign)); return 0; } } else { // This is a bitfield reference. LoadInst *LI = Builder.CreateLoad(LV.Ptr, isVolatile, "tmp&quot...
2013 Jan 20
2
[LLVMdev] [cfe-dev] codegen of volatile aggregate copies (was "Weird volatile propagation" on llvm-dev)
...e detailed access behavior is not very cleanly specified and it is > unwise to depend on it". The new SROA implementation is conservatively > correct, but behaves differently. > > I believe we should either : > - rework methods AggExprEmitter::EmitCopy and > CodeGenFunction::EmitAggregateCopy (from > clang/lib/CodeGen/CGExprAgg.cpp) to codegen differently the copy when > either the source or the destination is volatile, > I think this is bad... > - specify cleanly the memcpy intrinsic with respect to volatile behaviour > I agree that this is what we should do. I too...
2013 Jan 20
0
[LLVMdev] codegen of volatile aggregate copies (was "Weird volatile propagation" on llvm-dev)
...anual specifies that "The detailed access behavior is not very cleanly specified and it is unwise to depend on it". The new SROA implementation is conservatively correct, but behaves differently. I believe we should either : - rework methods AggExprEmitter::EmitCopy and CodeGenFunction::EmitAggregateCopy (from clang/lib/CodeGen/CGExprAgg.cpp) to codegen differently the copy when either the source or the destination is volatile, - specify cleanly the memcpy intrinsic with respect to volatile behaviour I would prefer option #2 as having a parameter whose effect is unspecified does not make it very...
2007 Nov 07
0
[LLVMdev] RFC: llvm-convert.cpp Patch
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
2008 Feb 15
0
[LLVMdev] an llvm-gcc bug
On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote: > > On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: > >> >> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: >> >>>>> Alternatively I can take the Padding bit into account in the >>>>> StructType::get code somehow. Anyone have a strong opinion? >>>> >>>>
2007 Nov 07
7
[LLVMdev] RFC: llvm-convert.cpp Patch
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
2008 Feb 15
3
[LLVMdev] an llvm-gcc bug
On Feb 15, 2008, at 10:23 AM, Devang Patel wrote: > > On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote: > >>>> Alternatively I can take the Padding bit into account in the >>>> StructType::get code somehow. Anyone have a strong opinion? >>> >>> Shouldn't it be a map from the gcc type to the padding info? >>> That said, you can get
2007 Oct 26
0
[LLVMdev] RFC: llvm-convert.cpp Patch
...> -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 align...
2013 Jan 21
0
[LLVMdev] [cfe-dev] codegen of volatile aggregate copies (was "Weird volatile propagation" on llvm-dev)
...havior is not very cleanly specified and it is > unwise to depend on it". The new SROA implementation is conservatively > correct, but behaves differently. > > I believe we should either : > - rework methods AggExprEmitter::EmitCopy and > CodeGenFunction::EmitAggregateCopy (from > clang/lib/CodeGen/CGExprAgg.cpp) to codegen differently the copy when > either the source or the destination is volatile, > > > I think this is bad... > > > - specify cleanly the memcpy intrinsic with respect to volatile > behaviour > > &g...
2013 Jan 18
2
[LLVMdev] Weird volatile propagation ?
Hi All, Using clang+llvm at head, I noticed a weird behaviour with the following reduced testcase : $ cat test.c #include <stdint.h> struct R { uint16_t a; uint16_t b; }; volatile struct R * const addr = (volatile struct R *) 416; void test(uint16_t a) { struct R r = { a, 1 }; *addr = r; } $ clang -O2 -o - -emit-llvm -S -c test.c ; ModuleID = 'test.c' target
2008 Feb 15
4
[LLVMdev] LLVMdev Digest, Vol 44, Issue 47
...apping between gcc types and llvm types. > > > > This is tricky and probably won't work. Padding info is in llvm struct > > type and CopyAggregate() is operating on llvm type. There is not any > > way to map llvm type back to gcc type. Am I missing something ? > > EmitAggregateCopy has the gcc type. It would be reasonable to have > CopyAggregate walk the GCC type in parallel with the llvm type, at > least in simple cases. In more complex cases, it could give up. > > -Chris > > > ------------------------------ > > Message: 3 > Date: Fri, 15 Feb...
2008 Feb 15
0
[LLVMdev] LLVMdev Digest, Vol 44, Issue 47
...lvm types. > > > > > > This is tricky and probably won't work. Padding info is in llvm struct > > > type and CopyAggregate() is operating on llvm type. There is not any > > > way to map llvm type back to gcc type. Am I missing something ? > > > > EmitAggregateCopy has the gcc type. It would be reasonable to have > > CopyAggregate walk the GCC type in parallel with the llvm type, at > > least in simple cases. In more complex cases, it could give up. > > > > -Chris > > > > > > ------------------------------ > >...
2009 Jan 09
2
[LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment
...VM::EmitVIEW_CONVERT_EXPR LValue LV = EmitLV(Op); assert(!LV.isBitfield() && "Expected an aggregate operand!"); bool isVolatile = TREE_THIS_VOLATILE(Op); - unsigned Alignment = expr_align(Op) / 8; + unsigned Alignment = LV.getAlignment(); EmitAggregateCopy(Target, MemRef(LV.Ptr, Alignment, isVolatile), TREE_TYPE(exp)); @@ -5885,9 +5896,10 @@ LValue TreeToLLVM::EmitLV_DECL(tree exp) Value *Decl = DECL_LLVM(exp); if (Decl == 0) { if (errorcount || sorrycount) { - const PointerType *Ty = - PointerType:...