[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 5:09 PM, Chris Lattner wrote:

>>>> 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?
>
> I discussed this with Bill today.  The problem is that we have:
>
> llvm.memcpy(p, q, 8, 1/*alignment)
>
> this gets turned into an 8-byte load and an 8-byte store, but the
> alignment (of 1) from the memcpy isn't put onto the load or store, so
> the legalizer thinks they are properly aligned.

Ok, this makes sense. I'd thought the memcpy alignment was 4.

Evan

>
> There is a separate issue of "maybe we should align this thing", but
> it is a performance, not correctness, issue.
>
> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits