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