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. Evan On Oct 23, 2007, at 5:11 PM, Bill Wendling wrote: > On 10/23/07, Chris Lattner <[EMAIL PROTECTED]> wrote: >>> URL: http://llvm.org/viewvc/llvm-project?rev=43270&view=rev >>> Log: >>> If there's an unaligned memcpy to/from the stack, don't lower it. >>> Just call the >>> memcpy library function instead. >> >> Hey Bill, >> >> There is nothing specific about the stack here, please just make it >> depend on whether the alignment of the src/dest pointers are >> sufficient. >> > Are you certain? When Evan and I looked at it, it seemed like it was > mostly having problems with the stack pointer and alignment. If it > wasn't aligned for PPC, then it would barf. > > I'm that's not the case, then this would be the patch, right? > > if (Size % Align != 0) > break; > > -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
