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