This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory
- From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 13 Feb 2010 19:25:08 -0000
- Subject: [Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory
- References: <bug-43058-10053@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-13 19:25 -------
limit += limit * PARAM_VALUE (PARAM_LARGE_FUNCTION_GROWTH) / 100;
/* Check the size after inlining against the function limits. But allow
the function to shrink if it went over the limits by forced inlining. */
newsize = cgraph_estimate_size_after_inlining (times, to, what);
if (newsize >= to->global.size
&& newsize > PARAM_VALUE (PARAM_LARGE_FUNCTION_INSNS)
&& newsize > limit)
{
this allows unbounded growth based on PARAM_LARGE_FUNCTION_GROWTH, ignoring
PARAM_LARGE_FUNCTION_INSNS. Shouldn't we at least limit
/* When inlining large function body called once into small function,
take the inlined function as base for limiting the growth. */
if (inline_summary (to)->self_size > inline_summary(what)->self_size)
limit = inline_summary (to)->self_size;
else
limit = inline_summary (what)->self_size;
limit += limit * PARAM_VALUE (PARAM_LARGE_FUNCTION_GROWTH) / 100;
so that limit is at most PARM_LARGE_FUNCTION_INSNS * PARM_LARGE_FUNCTION_GROWTH
/ 100?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058