--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #7 from hubicka at gcc dot gnu dot org 2008-11-11 20:09 ---
Current implementation of inliner is perfectly unaware of the debug info size
implications. There is alternative to limit number of BLOCKS in function body
growth same way as we limit stack usage that would just add
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37709
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-02 14:26 ---
The difference is mainly that HEAD inlines all func_* calls, while 4.3 keeps
many of them around (I see 30 call func_* insns in 4.3). The 4.4 .text is
about half the size of 4.3 .text (i.e. inliner did much better job
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-10-02 13:02 ---
We optimize func_1 to
func_1:
movwg_290(%rip), %ax
movl$0, g_3(%rip)
cwtl
ret
inlining all its callees recursively ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=377
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-10-02 12:56 ---
/* When we are not doing full debug info, we however can keep around
only the used variables for cfgexpand's memory packing saving quite
a lot of memory. */
else if (debug_info_level ==
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-10-02 11:06 ---
We seem to accumulate an awful huge stack of BLOCKs during inlining ... are
BLOCKs shared? Maybe we can avoid copying equivalent ones.
This testcase is bad, as in the end we will optimize it all away to a constant
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-01 23:48 ---
The inlininer is going crazy some how.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
