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