Inline heuristics tweek
Jan Hubicka
hubicka@ucw.cz
Sun Oct 23 18:46:00 GMT 2011
Hi,
while looking into the inlining dumps I noticed that by adding extra logic to identify
inlining benefits, the badness metric is now really scaled down. For tramp3d in ranges
from 0 to 400 that is quite coarse for thousdands of functions. This patch scales
it up and makes the overflow situations to be handled better.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
Index: ipa-inline.c
===================================================================
--- ipa-inline.c (revision 180328)
+++ ipa-inline.c (working copy)
@@ -822,8 +822,10 @@
/* Result must be integer in range 0...INT_MAX.
Set the base of fixed point calculation so we don't lose much of
precision for small bandesses (those are interesting) yet we don't
- overflow for growths that are still in interesting range. */
- badness = ((gcov_type)growth) * (1<<18);
+ overflow for growths that are still in interesting range.
+
+ Fixed point arithmetic with point at 8th bit. */
+ badness = ((gcov_type)growth) * (1<<(19+8));
badness = (badness + div / 2) / div;
/* Overall growth of inlining all calls of function matters: we want to
@@ -838,10 +840,14 @@
We might mix the valud into the fraction by taking into account
relative growth of the unit, but for now just add the number
into resulting fraction. */
+ if (badness > INT_MAX / 2)
+ {
+ badness = INT_MAX / 2;
+ if (dump)
+ fprintf (dump_file, "Badness overflow\n");
+ }
growth_for_all = estimate_growth (callee);
badness += growth_for_all;
- if (badness > INT_MAX - 1)
- badness = INT_MAX - 1;
if (dump)
{
fprintf (dump_file,
More information about the Gcc-patches
mailing list