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

[Evan Cheng]

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.

Evan


On Oct 23, 2007, at 5:11 PM, Bill Wendling wrote:

> On 10/23/07, Chris Lattner <clattner at apple.com> wrote:
>>> URL: http://llvm.org/viewvc/llvm-project?rev=43270&view=rev
>>> Log:
>>> If there's an unaligned memcpy to/from the stack, don't lower it.
>>> Just call the
>>> memcpy library function instead.
>>
>> Hey Bill,
>>
>> There is nothing specific about the stack here, please just make it
>> depend on whether the alignment of the src/dest pointers are  
>> sufficient.
>>
> Are you certain? When Evan and I looked at it, it seemed like it was
> mostly having problems with the stack pointer and alignment. If it
> wasn't aligned for PPC, then it would barf.
>
> I'm that's not the case, then this would be the patch, right?
>
>          if (Size % Align != 0)
>            break;
>
> -bw
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits