On Nov 6, 2007, at 6:07 PM, Dale Johannesen wrote:> > On Nov 6, 2007, at 5:45 PM, Bill Wendling wrote: >> $ more testcase.c.t03.generic >> Qux () >> { >> static char C.0[11] = {0}; >> char Bar[11]; >> >> Bar = C.0; >> } >> >> Anyway, it turns out that the gimplifier was generating the correct >> alignment, but it was being overridden in assemble_variable(): >> >> /* On some machines, it is good to increase alignment >> sometimes. */ >> if (! DECL_USER_ALIGN (decl)) >> { >> #ifdef DATA_ALIGNMENT >> align = DATA_ALIGNMENT (TREE_TYPE (decl), align); >> #endif >> #ifdef CONSTANT_ALIGNMENT >> => if (DECL_INITIAL (decl) != 0 && DECL_INITIAL (decl) !>> error_mark_node) >> align = CONSTANT_ALIGNMENT (DECL_INITIAL (decl), align); >> #endif >> } > > Not sure I'm getting it, is this Bar itself or the constructed C.0 > that's getting realigned? >It's C.0 that's getting realigned. -bw
On Nov 7, 2007, at 12:16 AM, Bill Wendling wrote:> On Nov 6, 2007, at 6:07 PM, Dale Johannesen wrote: >> >> Not sure I'm getting it, is this Bar itself or the constructed C.0 >> that's getting realigned? >> > It's C.0 that's getting realigned.OK then, it looks like other people have made the points I was going to, but briefly: Using DECL_USER_ALIGN is wrong; that is for user-specified alignments, and if you use it for something else, you'll break that. The alignment on memcpy needs to take both the source & destination into account. You seem to have gotten this far. Unfortunately that bit of llvm- convert is a maze of recursive little passages, but your last patch seems to be thinking along the right lines. Would it be terrible to drop the alignment on memcpy altogether? The source and destination have alignments and llvm should be able to figure out what the safe alignment is for memcpy. This is a target-dependent decision anyway; misaligned loads are a good idea on some targets, not on others.
On Wed, 7 Nov 2007, Dale Johannesen wrote:> Would it be terrible to drop the alignment on memcpy altogether? The > source and destination have alignments and llvm should be able to figure > out what the safe alignment is for memcpy. This is a target-dependent > decision anyway; misaligned loads are a good idea on some targets, not > on others.No, it wouldn't be terrible. This sounds like a good short-term fix. -Chris -- http://nondot.org/sabre/ http://llvm.org/
On 11/7/07, Dale Johannesen <dalej at apple.com> wrote:> > OK then, it looks like other people have made the points I was going > to, but briefly: > > Using DECL_USER_ALIGN is wrong; that is for user-specified > alignments, and if > you use it for something else, you'll break that. >Okay.> The alignment on memcpy needs to take both the source & destination > into account.I agree. But I was thinking that there was a more fundamental problem, i.e. that GCC was changing the alignment of the constructor without taking the destination's alignment into account -- that is, it's not changing the destination's alignment and/or checking it beforehand.> You seem to have gotten this far. Unfortunately that bit of llvm- > convert is a maze of > recursive little passages,Tell me about it! ;-)> but your last patch seems to be thinking along the right lines. >:-) -bw