Bug 39621 - Delaying operation to end of function causes high stack usage
Delaying operation to end of function causes high stack usage
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: tree-optimization
4.3.3
: P3 normal
: 4.7.0
Assigned To: Not yet assigned to anyone
: missed-optimization
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-03 08:47 UTC by Wouter van Gulik
Modified: 2011-12-30 06:08 UTC (History)
2 users (show)

See Also:
Host: linux-x86
Target: multiple (at least: arm, x86, avr)
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-04-30 07:54:44


Attachments
C file showing bug (1.04 KB, application/octet-stream)
2009-04-03 08:48 UTC, Wouter van Gulik
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wouter van Gulik 2009-04-03 08:47:07 UTC
Function like this:

extern int bar(void);
int foo(int in)
{
 in += bar();
 in += bar(); 
 in += bar(); 
 in += bar(); 
 return in;
}

Result in putting the output of bar on stack, and adding the result just before returning. It continues on until it about 16 iteration. Meaning useless heavy stack usage and for some targets much code.

The general assembler will look like this:

push stack
call bar
put result on stack
call bar
put result on stack
call bar
put result on stack
call bar
add to in
add stack to in
add stack to in
add stack to in
pop stack
return 

This behaviour is seen on recent version for arm (4.3.3), x86 (4.3.3) and avr (4.3.2).

Interresting is that providing the 'register' keyword on input for -00 'solves' the problem.

It seems that GCC delays the add operations until returning, however delaying beyond a function call is normally pointless and more expensive in terms of code size and cycles.

See attached file for a test case with for unroll-loops and normal code.
Comment 1 Wouter van Gulik 2009-04-03 08:48:51 UTC
Created attachment 17580 [details]
C file showing bug

compile using:
gcc -S -funroll-loops -0[0123s] main.c
Comment 2 Hans-Peter Nilsson 2009-04-06 17:16:12 UTC
It'd be nice to know if -fno-tree-reassoc helped here.
Comment 3 Wouter van Gulik 2009-04-07 07:55:07 UTC
(In reply to comment #2)
> It'd be nice to know if -fno-tree-reassoc helped here.
> 

Yes that solves the problem. I tried for -O[123s] (x86 and avr).
Comment 4 Andrew Pinski 2011-12-30 06:08:28 UTC
Fixed on the trunk most likely by:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49749