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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits _______________________________________________ llvm-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
