[Bug middle-end/22605] Alignment of struct on stack is no longer the maxium alignment

["wilson at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From wilson at gcc dot gnu dot org  2005-07-22 20:10 -------
I think the 16-byte over-alignment in gcc-3.x is a mis-feature.  Anything over
8-byte alignment here is useless.

However, I also think the 4-byte alignment in gcc-4.0 is a mis-feature.  It just
looks wierd to me that we have a 64-bit target with 64-bit stack slots, and we
are allocating a 64-bit structure across two stack slots.  Yes, what gcc is
doing is valid, as the structure has 4-byte alignment.  However, that isn't the
question here.  The question is whether it is desirable.

If we over-align the structure to 8-bytes to fit in a single stack slot, then we
can use ld8/st8 instructions to copy it around.  If we don't over-align it, then
we have to copy it by parts which is slower and takes more instructions.  On a
target like IA-64 where performance is more important than memory usage, it
appears that we have made the wrong choice here.  I think over-aligning to
8-bytes in this case will give better (faster) code at the cost of a negligible
frame size increase.

We have target macros like DATA_ALIGNMENT and CONSTANT_ALIGNMENT so that we can
give extra alignment in cases where we know this will improve performance.  But
we have no such macro for variables allocated on the stack.  In the past, we
probably didn't need one, because we were already over-aligning structures on
the stack by default.  Now that we don't over-align on the stack by default,
maybe we should have one.

I haven't done any study to see whether this is beneficial.  This might be a
interesting little optimization project for someone to try.  If an aggregate
allocated on the stack has alignment less than the word size, but has size equal
to or larger than the word size, then try over-aligning to the word size, and
see if this affects SPEC results on a STRICT_ALIGNMENT target.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22605