------- 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