[Bug c/22605] New: Allocation of structures across stack slots

[Bug c/22605] New: Allocation of structures across stack slots

[ianw at gelato dot unsw dot edu dot au]

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

-- 
           Summary: Allocation of structures across stack slots
           Product: gcc
           Version: 4.0.1
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ianw at gelato dot unsw dot edu dot au
                CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-linux-gnu


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-22 18:05 -------
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.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end
            Summary|Allocation of structures    |Alignment of struct on stack
                   |across stack slots          |is no longer the maxium
                   |                            |alignment


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

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

[wilson 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