> Hi, > > On Wed, Dec 21, 2011 at 05:29:51PM +0100, Jan Hubicka 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)? > > no, it is really estimate_ipcp_clone_size_and_time that returns size > estimate -2. In fact, the subtraction you described does not occur on > that code path at all because I do it only for constants that occur in > all contexts (from all callers) and this assert is on the path dealing > with estimates of effects of constants that there are only in some > contexts. > > The reason why I don't do it for constants that come from only a > subset of callers is that some of these callers might themselves > require context specific cloning to provide tha value but when actual > decisions are being made later on, they would not be cloned. So I > don't know the set of callers that provide the constant at this time > and cannot do the subtraction. > > > > > In that case I guess the patch is OK, but please update the comment, > > Well, it't not the case, so what do you think?
Hmm, it is estimate_ipcp_clone_size_and_time bug then. I will look into that today. Honza > > Martin
