[Bug optimization/5477] gcc 3.0.x reserves a large stack frame, but uses only some parts of it

["espenlaub at informatik dot uni-ulm dot de" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


espenlaub at informatik dot uni-ulm dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED


------- Additional Comments From espenlaub at informatik dot uni-ulm dot de  2003-06-23 10:06 -------
Marked bug as fixed since both gcc-3.2 and gcc-3.3 use only 28 bytes of stack
space (and in some blocks of the function temporarily about twice as much). 
This is actually much better than gcc-2.95.3, and 92% less stack space usage
than gcc-3.0).

It is still not really optimal, but something usable.  It will probably
eventually reappear as a bug (not from me, if the stack usage remains
approximately at this level), since generating code like

...
        subl    $12, %esp
        pushl   $32
        call    __console_putchar
        addl    $16, %esp
...

for a simple subroutine call (a snippet of the generated code from the
attachment with gcc-3.3) with a single integer parameter is nowhere near
optimal.  The 12 bytes that are reserved at the beginning are clearly unused, so
the "subl $12,%esp" should be removed entirely and the "addl $16,%esp" should be
adjusted to "addl $4,%esp".  But it seems that this obvious local optimization
is not done due to problems detecting all unused stack slots.  I don't know
enough about the gcc internals to help in this area.

Sorry about the long delay since the last feedback.  It seems that the
distributed incremental garbage collector in my brain removed something that was
still referenced from an external source ;-)  Thanks for reminding me.