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