Bug 9624 - Stack space allocation too gratuitious
Summary: Stack space allocation too gratuitious
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.2
: P3 normal
Target Milestone: 4.0.0
Assignee: Not yet assigned to anyone
: 11232 13623 (view as bug list)
Depends on:
Reported: 2003-02-08 00:26 UTC by dath
Modified: 2004-09-13 10:08 UTC (History)
3 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2003-11-25 08:48:12


Note You need to log in before you can comment on or make changes to this bug.
Description dath 2003-02-08 00:26:00 UTC
gcc 3.2 allocates more stack space than necessary in many cases.  Given the code listed in the "How-To-Repeat" section, I see the following amounts of space allocated on the stack in function():

buf[1-2]   subl    $4, %esp
buf[3]     subl    $24, %esp
buf[4]     subl    $4, %esp
buf[5-7]   subl    $24, %esp
buf[8]     subl    $8, %esp
buf[9-16]  subl    $24,%esp
buf[17-32] subl    $40, %esp

...  I quit there, but I believe the oddities do continue further.  I used the following command line to produce these results:

gcc -DSIZE=1 -S -o test1.S test.c
gcc -DSIZE=2 -S -o test2.S test.c
gcc -DSIZE=3 -S -o test3.S test.c

Below is the complete output from test3.S (sorry don't know if you need or want it, but just to error on the side of too much information...):
        .file   "test.c"
        .align 2
.globl function
        .type   function,@function
        pushl   %ebp
        movl    %esp, %ebp
        subl    $24, %esp
        .size   function,.Lfe1-function
        .align 2
.globl main
        .type   main,@function
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        andl    $-16, %esp
        movl    $0, %eax
        subl    %eax, %esp
        call    function
        .size   main,.Lfe2-main
        .ident  "GCC: (GNU) 3.2"

Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.2/specs

SuSE Linux Enterprise Server 8 (SLES8)
Linux alice 2.4.19-4GB #1 Mon Oct 21 18:28:11 UTC 2002 i686 unknown

void function() { char buf[SIZE]; }
int main(void){ function(); }

 Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada --enable-libgcj --with-gxx-include-dir=/usr/i nclude/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux
 Thread model: posix
 gcc version 3.2
Comment 1 Wolfgang Bangerth 2003-02-08 00:33:46 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed. Martin Buchholz send a couple of optimization
    reports a couple of weeks ago, in which I also documented
    this. Note that allocating too much stack space is not 
    wrong, it's just a waste. And it reduces locality of data
    with the usual problems with cache sizes.
Comment 2 Wolfgang Bangerth 2003-06-18 13:43:33 UTC
*** Bug 11232 has been marked as a duplicate of this bug. ***
Comment 3 Andrew Pinski 2003-07-28 00:23:36 UTC
On the tree-ssa branch, gcc gcc does not allocate space for buf at all but it does not fix 
the problem if you use buf, the space allocated is still too gratuitious.
Comment 4 Andrew Pinski 2003-11-25 08:48:11 UTC
This looks like an aligment issue.
Comment 5 Andrew Pinski 2004-01-09 02:44:30 UTC
*** Bug 13623 has been marked as a duplicate of this bug. ***
Comment 6 Joel Yliluoma 2004-09-08 11:29:53 UTC
Alignment indeed rounds up the size, but consider this code:
  void xxx(void)
      unsigned x[12451];
No matter which optimization settings you run it at (even with
-fomit-frame-pointer), gcc will still emit code that allocates 49804+ bytes from
stack and immediately releases it. On x86, for example, it does this:
      subl $49820, %esp
      addl $49820, %esp

Same thing also happens for unused local structs and classes.
The stack space isn't freed.

This does not happen with simple variables (ints and such), probably because the
compiler treats them as register variables by default and only allocates stack
space when it has no other choice.
Comment 7 Joel Yliluoma 2004-09-08 11:31:39 UTC
Err, meant "needlessly allocated" in comment #6, not "not freed".
Comment 8 Andrew Pinski 2004-09-08 18:27:32 UTC
I should note that on the mainline now, we don't allocate the stack space for unused arrays.
Comment 9 Richard Henderson 2004-09-13 10:08:18 UTC
Indeed, fixed for 4.0.  Will not be fixed in previous versions.