[llvm-commits] [llvm] r43270 - in /llvm/trunk: lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp test/CodeGen/PowerPC/2007-10-23-UnalignedMemcpy.ll

[Evan Cheng]

On Oct 23, 2007, at 6:18 PM, Chris Lattner wrote:

>
> On Oct 23, 2007, at 6:00 PM, Evan Cheng wrote:
>
>> Now that I think about it some more. The bug Bill and I looked at
>> appears to be just a PPC prologue / epilogue lowering bug. It doesn't
>> seem to be rounding up the size of the stack correctly.
>>
>> Suppose the size of source frame object is 5, this can be lowered  
>> into
>> a pair of 4 byte load / store and a pair of 1 byte load / store:
>>
>> fi#0 : size 5, align 4
>>
>> v1 = load i32 [fi#0], 0
>> store v1
>> v2 = load i8 [fi#0], 4
>> store v2
>>
>> If fi#0 offset 0 is accessed off sp, then all is well, If it's
>> accessed off fp, then the 32-bit load is unaligned. The problem is
>> probably as simple as rounding up the size of the stack to be  
>> multiple
>> of 4 and adjust the fp index accordingly.
>
> The frame lowering stuff is right.  The PPC backend is using the
> redzone, so the stack pointer doesn't need to move.  This is just
> accessing 33 bytes below the stack pointer, which isn't aligned.
> Again, in this specific case you could force the frame object to be
> aligned or something, but that wouldn't help the case when some
> random unaligned pointer is memcpy'd.

It's not memcpy'ing unaligned pointer. The lowering code does check  
that.

If my memory is right, in this case, the frame object itself is  
aligned on 4-byte boundary. The memcpy size is 33, that is lowered  
into 4 pairs of 8-byte load / store and 1 pair of 1 byte load /  
store. It's issuing a 1-byte load from r1+32 and 4 8-byte loads from  
r1+8, r1+16, r1+24. It's faulting on one of the 8-byte load so it  
must be r1 is mis-aligned.

Bill, please post the assembly code. Thanks.

Evan

>
> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits