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

[Chris Lattner]

>>> 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.

There is a separate issue of "maybe we should align this thing", but  
it is a performance, not correctness, issue.

-Chris