On 10/24/07, Evan Cheng <[EMAIL PROTECTED]> 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 _______________________________________________ llvm-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
