[llvm-commits] [llvm] r43270 - in /llvm/trunk: lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp test/CodeGen/PowerPC/2007-10-23-UnalignedMemcpy.ll
Chris Lattner
clattner at apple.com
Wed Oct 24 17:09:34 PDT 2007
>>> 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
More information about the llvm-commits
mailing list