2011/12/22 Jan Hubicka <hubi...@ucw.cz>: >> 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.
But why throw program shrink amount and function size together - that does not make sense (at least if you expect only positive final function size). > At least that is my understanding of the code here. Martin? > > Honza
