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

[Evan Cheng]

On Oct 24, 2007, at 12:03 AM, Bill Wendling wrote:

> On Oct 23, 2007, at 11:29 PM, Evan Cheng wrote:
>> 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.
>>
> Here's what it's doing in PPCRegisterInfo::eliminateFrameIndex().
>
> (gdb) call MF.dump()
> # Machine code for Bork():
>    <fi #0>: size is 33 bytes, alignment is 1 byte, at location [SP-33]

Ok, then the problem is just this stack object is misaligned? I  
thought the source specified this alloca should be 4-byte aligned?

Evan

>
> entry: 0x1203860, LLVM BB @0x1201480, ID#0:
>          %r2 = LIS8 <ga:C.0.1173>
>          %r2 = LD <ga:C.0.1173>, %r2<kill>
>          %r3 = LBZ 32, %r2
>          %r4 = LD 0, %r2
>          STB %r3<kill>, 32, <fi#0>
>          %r3 = LD 2, %r2
>          %r5 = LD 4, %r2
>          %r2 = LD 6, %r2<kill>
>          STD %r4<kill>, 0, <fi#0>
>          STD %r3<kill>, 2, <fi#0>
>          STD %r5<kill>, 4, <fi#0>
>          STD %r2<kill>, 6, <fi#0>
>          BLR 20, %cr0<kill>
>
> # End machine code for Bork().
>
> The second time through (while processing the "STD %r4<kill>, 0,
> <fi#0>"), the "STB" is now "STB %r3<kill>, -1, %r1" and the Offset is
> -33.
>
> -bw
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits