> On Wed, Dec 21, 2011 at 5:29 PM, Jan Hubicka <hubi...@ucw.cz> wrote: > >> Hi, > >> > >> given that we already have a workaround for zero size increase > >> estimates from estimate_ipcp_clone_size_and_time, I see little reason > >> not to extend it to negative values too, 0 is really just as bad as -2 > >> that we are getting in the testcase. Hopefully this will allow peple > >> who hit this bug proceed with their testing. > >> > >> Bootstrapped and tested on x86-64-linux with no regressions. > >> OK for trunk? > > > > Hmm, so the size value is not negative because > > estimate_ipcp_clone_size_and_time > > would return 0 or negative value but because of > > size -= stats.n_calls * removable_params_cost > > (i.e. the callee function is so small that the program will really shrink > > because > > of reduced call overhead)? > > That doesn't make sense - is the 'removable_params_cost' maybe not > in-line with what estimate_num_insns computes for the param part > of the call cost?
n_calls is the number of calls of the clonned function, not number of calls within the clonned function. When you have function that is called 1000 times and is very small, clonning it and removing one of its arguments makes your program shrink. At least that is my understanding of the code here. Martin? Honza
