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"...
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:...