> > This was not for jump shortening, but the inliner heuristics. > > > > In the worst case we could separate the two, would be a larger > > patch though. > > Actually it's already separated, I don't affect the jump shortening > at all. Only the inliner code adds the limit. > > So it would depend whether 1000 * weight is large enough for inlining. > Honza?
I think it is safely more than enough. 1000*weight makes the function safely uninlinable. So only it cuts of precision in large function growth/large unit growth logic. The logic is skewed here: large function growth is there really for compiler visible code to prevent non-linear algorithm explosion. For large unit growth I duno - in a way those gigantic asm statements that are not going to be duplicated can be tought as not part of the unit for this putpose, too. So I am fine with the cutoff. We may need to add more overflow guards (we already have quite few for time) that makes me wonder if all this should not be done all in saturating arithmetic now when it can be done theoretically with one C++ class? Honza > > -Andi
