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,

Reply via email to