[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #24 from rguenther at suse dot de  2010-04-03 21:13 -------
Subject: Re:  [4.5 regression] 0.5% code size
 regression caused by r147852

On Sat, 3 Apr 2010, hubicka at ucw dot cz wrote:

> ------- Comment #23 from hubicka at ucw dot cz  2010-04-03 21:02 -------
> Subject: Re:  [4.5 regression] 0.5% code size
>         regression caused by r147852
> 
> > 1) overall_size is reduced twice for the same function, once in
> >    cgraph_clone_inlined_nodes, once in cgraph_mark_inline_edge (which calls
> >    the former), this leads to double accounting
> 
> Hmm, yep, it is bug here and I guess it makes tramp3d unhappy since it relies
> on
> the overall unit growth.  I will try to fix this and retune to see if this can
> be
> used to help the CSiBE regression that also might be related to this thinko.
> 
> > 2) cgraph_check_inline_limits checks the wrong size against the 
> >    PARAM_LARGE_FUNCTION_INSNS parameter, it needs to use the original size,
> >    not the one estimated after inlining.
> Well, PARAM_LARGE_FUNCTION_INSNS was meant to let small functions to grow as
> much
> as they want until the threshold is hit, so size after inlining makes sense
> here.

But the the code as-is allows unlimited growth of a function (well,
by PARAM_LARGE_FUNCTION_GROWTH for each inlining; the limit is
basically PARAM_LARGE_FUNCTION_INSNS * (1 + 
PARAM_LARGE_FUNCTION_GROWTH/100) ^ n with n being the number of
functions we inline into the function).  So it's not really a
limit of the growth but of the growth rate ;)

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436