Bug 22605 - Alignment of struct on stack is no longer the maxium alignment
Alignment of struct on stack is no longer the maxium alignment
Status: NEW
Product: gcc
Classification: Unclassified
Component: middle-end
4.0.1
: P3 enhancement
: ---
Assigned To: Not yet assigned to anyone
: missed-optimization
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-22 04:54 UTC by ianw
Modified: 2007-09-29 20:42 UTC (History)
1 user (show)

See Also:
Host:
Target: ia64-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-09-29 20:06:29


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ianw 2005-07-22 04:54:50 UTC
Hi,

gcc 4 seems quite a bit smarter at keeping the stack smaller, and as you can see
below allocates the 8 byte structure across two stack slots.

It did break something, which drew this to my attention, and James Wilson
already some analsysis in
http://www.gelato.unsw.edu.au/archives/linux-ia64/0507/1885.html.  Quoting him

 > If gcc-3.4 and earlier, some structures (BLKmode structures) were being
 > over-aligned when allocated to stack slots.  They always got the maximum
 > alignment (16 bytes for IA-64) instead of their natural alignment.  It
 > isn't clear why.  I think this was an accident of implementation.  We
 > were basing variable alignment on modes instead of type alignment, and
 > since some BLKmode structures do require max alignment, we had to give
 > it to all of them.

We came to the conclusion that we are unsure if this is a bug or a feature.  I
am unsure if the larger stack space required is a good trade off against
possible better code.

Thanks,

-i

--- sample ---

ianw@lime:/tmp$ cat test.c
#include <stdio.h>

struct disk_stat {
        int fd;
        unsigned count;
};

int main(void)
{
        int blah;
        struct disk_stat test;

        printf("%p\n", &blah);

        printf("%p\n", &test);
}
ianw@lime:/tmp$ gcc-3.4 -o test test.c
ianw@lime:/tmp$ ./test
0x60000fffffcdf480
0x60000fffffcdf490

ianw@lime:/tmp$ gcc-4.0 -o test test.c
ianw@lime:/tmp$ ./test
0x60000fffffd57490
0x60000fffffd57494
Comment 1 Andrew Pinski 2005-07-22 18:05:32 UTC
Huh?  I don't understand what do you mean by stack slots because there is no such thing in GCC.
Do you mean you want disk_stat aligned to 16 byte? 
Note the alignment of disk_stat is 4byte so GCC should not require it to be 8byte alignment.
Comment 2 Jim Wilson 2005-07-22 20:10:48 UTC
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.
Comment 3 Richard Biener 2007-09-29 20:06:29 UTC
As of comment #2 this is a possible enhancement for non -Os (or stack saving
mode) on STRICT_ALIGNMENT targets.
Comment 4 Andrew Pinski 2007-09-29 20:42:11 UTC
if you want aligned arrays use attribute aligned.  Now GCC should automatically doing it for non -Os/stack saving mode for optimization reasons but other than that, you cannot depend on the alignment.