User account creation filtered due to spam.

Bug 9624 - Stack space allocation too gratuitious
Summary: Stack space allocation too gratuitious
Status: RESOLVED FIXED
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
URL:
Keywords:
: 11232 13623 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-02-08 00:26 UTC by dath
Modified: 2004-09-13 10:08 UTC (History)
3 users (show)

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


Attachments

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"
        .text
        .align 2
.globl function
        .type   function,@function
function:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $24, %esp
        leave
        ret
.Lfe1:
        .size   function,.Lfe1-function
        .align 2
.globl main
        .type   main,@function
main:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        andl    $-16, %esp
        movl    $0, %eax
        subl    %eax, %esp
        call    function
        leave
        ret
.Lfe2:
        .size   main,.Lfe2-main
        .ident  "GCC: (GNU) 3.2"

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

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

How-To-Repeat:
void function() { char buf[SIZE]; }
int main(void){ function(); }

Unformatted:
 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.
    
    W.
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:
  _Z3xxxv:
      subl $49820, %esp
      addl $49820, %esp
      ret

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.