------- Additional Comments From rth at gcc dot gnu dot org 2005-02-03 02:23
-------
The balance of the problem appears to come from TER. We're building very large
constructs, such as
[z.c : 76] x.182 = -temp.218 + temp.220 - temp.688 - temp.222 + temp.224 +
temp.692 - temp.226 * 3 - temp.227 * 2 - temp.228 + temp.230 + temp.231 * 2 +
temp.232 * 3 - (int) *(cp - (uchar *) (unsigned int) *(temp.677 - 6B)) * 3 -
(int) *(cp - (uchar *) (unsigned int) *(temp.677 + -5B)) * 2 - (int) *(cp -
(uchar *) (unsigned int) *(temp.677 + -4B)) + (int) *(cp - (uchar *) (unsigned
int) *(temp.677 + -2B)) + (int) *(cp - (uchar *) (unsigned int) *(temp.677 +
-1B)) * 2 + (int) *(cp - (uchar *) (unsigned int) *temp.677) * 3 - temp.239 * 3
- temp.240 * 2 - temp.241 + temp.243 + temp.244 * 2 + temp.245 * 3 - temp.699 -
temp.247 + temp.249 + temp.703 - temp.251 + temp.253;
Instead of simply accumulating into X at each step, we're extending the
lifetime of all of the temporaries until the end. Ouch.
Anyway, if I use -Os -fno-tree-ter, the stack frame size drops to 40 bytes
from 256. And object size is much nicer too:
text data bss dec hex filename
2136 0 0 2136 858 a.out-34
2006 0 0 2006 7d6 a.out-noter
2809 0 0 2809 af9 a.out-ter
I'm not sure how best to attack this, Andrew. I think it's clear that turning
off TER entirely isn't the correct option, but I'm not sure how to throttle it
to keep things from running completely off the rails. Thoughts?
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com
Component|middle-end |tree-optimization
Last reconfirmed|2004-09-18 17:05:39 |2005-02-03 02:23:45
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549
