This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[tree-profiling] Fix some leftouts of previous patch


Hi,
this patch fix the frequency updating issues (I will still keep the
frequency updating around as I am not quite sure how we will want to
deal with the estimated profiles once available yet) and it also avoid
recursive inlining that helps some benchmarks.

Honza

2004-12-08  Jan Hubicka  <jh@suse.cz>
	* ipa-inline.c (cgraph_edge_badness): Simplify.
	(cgraph_decide_inlining_of_small_functions): Avoid recursive inlining.
	(cgraph_decide_inlining): Sanity check.
	* tree-inline.c (optimize_inline_calls): Recount frequencies.
Index: ipa-inline.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Attic/ipa-inline.c,v
retrieving revision 1.1.2.4
diff -c -3 -p -r1.1.2.4 ipa-inline.c
*** ipa-inline.c	7 Dec 2004 18:58:56 -0000	1.1.2.4
--- ipa-inline.c	8 Dec 2004 20:08:37 -0000
*************** cgraph_maybe_hot_edge_p (struct cgraph_e
*** 336,342 ****
  static int
  cgraph_edge_badness (struct cgraph_edge *edge)
  {
!   if (profile_info && flag_branch_probabilities && max_count)
      {
        int growth =
  	cgraph_estimate_size_after_inlining (1, edge->caller, edge->callee);
--- 336,342 ----
  static int
  cgraph_edge_badness (struct cgraph_edge *edge)
  {
!   if (max_count)
      {
        int growth =
  	cgraph_estimate_size_after_inlining (1, edge->caller, edge->callee);
*************** cgraph_decide_inlining_of_small_function
*** 604,609 ****
--- 604,637 ----
        if (!edge->inline_failed)
  	continue;
  
+       /* When not having profile info ready we don't weight by any way the
+          possition of call in procedure itself.  This means if call of
+ 	 function A from function B seems profitable to inline, the recursive
+ 	 call of function A in inline copy of A in B will look profitable too
+ 	 and we end up inlining until reaching maximal function growth.  This
+ 	 is not good idea so prohibit the recursive inlining.
+ 
+ 	 ??? When the frequencies are taken into account we might not need this
+ 	 restriction.   */
+       if (!max_count)
+ 	{
+ 	  where = edge->caller;
+ 	  while (where->global.inlined_to)
+ 	    {
+ 	      if (where->decl == edge->callee->decl)
+ 		break;
+ 	      where = where->callers->caller;
+ 	    }
+ 	  if (where->global.inlined_to)
+ 	    {
+ 	      edge->inline_failed
+ 		= (edge->callee->local.disregard_inline_limits ? N_("recursive inlining") : "");
+ 	      if (dump_file)
+ 		fprintf (dump_file, " inline_failed:Recursive inlining perfomed only for function itself.\n");
+ 	      continue;
+ 	    }
+ 	}
+ 
        if (!cgraph_maybe_hot_edge_p (edge) && growth > 0)
  	{
            if (!cgraph_recursive_inlining_p (edge->caller, edge->callee,
*************** cgraph_decide_inlining (void)
*** 711,716 ****
--- 739,745 ----
  	  max_count = e->count;
      }
    overall_insns = initial_insns;
+   gcc_assert (!max_count || (profile_info && flag_branch_probabilities));
  
    max_insns = ((HOST_WIDEST_INT) overall_insns
  	       * (100 + PARAM_VALUE (PARAM_INLINE_UNIT_GROWTH)) / 100);
Index: tree-inline.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-inline.c,v
retrieving revision 1.26.2.83.2.20
diff -c -3 -p -r1.26.2.83.2.20 tree-inline.c
*** tree-inline.c	7 Dec 2004 18:58:57 -0000	1.26.2.83.2.20
--- tree-inline.c	8 Dec 2004 20:08:37 -0000
*************** optimize_inline_calls (tree fn)
*** 2545,2550 ****
--- 2545,2554 ----
  	gcc_assert (e->inline_failed);
      }
  #endif
+   /* We need to rescale frequencies again to peak at REG_BR_PROB_BASE as inlining
+      loops might increase the maximum.  */
+   if (ENTRY_BLOCK_PTR->count)
+     counts_to_freqs ();
    /* Inlining a function body that contains a call to abort() can
       render some caller code "unreachable", as the CFG-builder knows
       that abort() never returns.  Such unreachable code will cause


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]