> On Fri, Nov 18, 2011 at 6:47 PM, Martin Jambor <mjam...@suse.cz> wrote: > > Hi, > > > > PR 50744 is an issue with an integer overflow when we propagate the > > estimated size and time effects from callees to callers. Because such > > paths in the parameter value graph can be arbitrarily long, we simply > > need to introduce an artificial cap on these values. This is what the > > patch below does. The cap should be more than enough for any > > reasonable values. > > > > Moreover, I have looked at how we then process the accumulated > > estimates and decided to compute evaluation ratio in > > good_cloning_opportunity_p in HOST_WIDEST_INT. Call graph frequencies > > are numerators of fractions with denominator 1000 and therefore > > capping the size and cost estimate as well as the frequency sums so > > that their multiplication would not overflow an int seems too > > constraining on 32bit hosts. > > > > Bootstrapped and tested on x86_64-linux without any problems, OK for > > trunk? > > This introduces host-dependent code generation differences, right? > You can simply use int64_t for code that is run on the host only.
Well, if we rely on int64_t being around now (that is probably the case with C++ switch), HOST_WIDEST_INT is always equivalent, isn't it? Honza