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

Bill Wendling isanbard at gmail.com
Wed Oct 24 17:47:10 PDT 2007


On 10/24/07, Evan Cheng <evan.cheng at apple.com> wrote:
>
> 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.
>
Um...so...since the Align that I get is 8 from the memcpy, how do I
get the alignment of the src/dst pointers?

-bw



More information about the llvm-commits mailing list