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

[Bill Wendling]

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]

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