On Oct 24, 2007, at 12:03 AM, Bill Wendling wrote: > On Oct 23, 2007, at 11:29 PM, Evan Cheng wrote: >> On Oct 23, 2007, at 6:18 PM, Chris Lattner wrote: >>> On Oct 23, 2007, at 6:00 PM, Evan Cheng wrote: >>>> Now that I think about it some more. The bug Bill and I looked at >>>> appears to be just a PPC prologue / epilogue lowering bug. It >>>> doesn't >>>> seem to be rounding up the size of the stack correctly. >>>> >>>> Suppose the size of source frame object is 5, this can be lowered >>>> into >>>> a pair of 4 byte load / store and a pair of 1 byte load / store: >>>> >>>> fi#0 : size 5, align 4 >>>> >>>> v1 = load i32 [fi#0], 0 >>>> store v1 >>>> v2 = load i8 [fi#0], 4 >>>> store v2 >>>> >>>> If fi#0 offset 0 is accessed off sp, then all is well, If it's >>>> accessed off fp, then the 32-bit load is unaligned. The problem is >>>> probably as simple as rounding up the size of the stack to be >>>> multiple >>>> of 4 and adjust the fp index accordingly. >>> >>> The frame lowering stuff is right. The PPC backend is using the >>> redzone, so the stack pointer doesn't need to move. This is just >>> accessing 33 bytes below the stack pointer, which isn't aligned. >>> Again, in this specific case you could force the frame object to be >>> aligned or something, but that wouldn't help the case when some >>> random unaligned pointer is memcpy'd. >> >> It's not memcpy'ing unaligned pointer. The lowering code does check >> that. >> >> 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? Evan > > entry: 0x1203860, LLVM BB @0x1201480, ID#0: > %r2 = LIS8 <ga:C.0.1173> > %r2 = LD <ga:C.0.1173>, %r2<kill> > %r3 = LBZ 32, %r2 > %r4 = LD 0, %r2 > STB %r3<kill>, 32, <fi#0> > %r3 = LD 2, %r2 > %r5 = LD 4, %r2 > %r2 = LD 6, %r2<kill> > STD %r4<kill>, 0, <fi#0> > STD %r3<kill>, 2, <fi#0> > STD %r5<kill>, 4, <fi#0> > STD %r2<kill>, 6, <fi#0> > BLR 20, %cr0<kill> > > # End machine code for Bork(). > > The second time through (while processing the "STD %r4<kill>, 0, > <fi#0>"), the "STB" is now "STB %r3<kill>, -1, %r1" and the Offset is > -33. > > -bw > > > > _______________________________________________ > 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
