Displaying 3 results from an estimated 3 matches for "emitaddr_expr".
2007 Nov 07
3
[LLVMdev] RFC: llvm-convert.cpp Patch
...-811,7 +811,7 @@
case STRING_CST:
case REALPART_EXPR:
case IMAGPART_EXPR:
- Result = EmitLoadOfLValue(exp, DestLoc);
+ Result = EmitLoadOfLValue(exp, DestLoc, Alignment);
break;
case OBJ_TYPE_REF: Result = EmitOBJ_TYPE_REF(exp); break;
case ADDR_EXPR: Result = EmitADDR_EXPR(exp); break;
@@ -2524,7 +2524,8 @@
/// EmitLoadOfLValue - When an l-value expression is used in a
context that
/// requires an r-value, this method emits the lvalue computation,
then loads
/// the result.
-Value *TreeToLLVM::EmitLoadOfLValue(tree exp, Value *DestLoc) {
+Value *TreeToLLVM:...
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
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