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

[Chris Lattner]

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.

-Chris