Remove early inlining from afdo pass

This pass removes early-inlining from afdo pass since all inlining should now
happen from early inliner.  I tedted this on spec and there are 3 inlines
happening here which are blocked at early-inline time by hitting large function
growth limit.  We probably want to bypass that limit, I will look into that
incrementaly.

This should make the non-inlined function profile merging hopefully easier.

It may still make sense to separate afdo inliner from early inliner to solve
the non-transitivity issues which is not that hard to do with current code
orgnaization. However this should be separate IPA pass rather then another
part of afdo pass, since it can be coneptually separate.

gcc/ChangeLog:

	* auto-profile.cc: Update toplevel comment.
	(early_inline): Remove.
	(auto_profile): Don't do early inlining.

diff --git a/gcc/auto-profile.cc b/gcc/auto-profile.cc
index 8a1d9f878c65be26424375a7d60a71eb82397408..3f8310e6324bf9ba458f6076e24ed85ea6a8971e 100644 (file)
--- a/gcc/auto-profile.cc
+++ b/gcc/auto-profile.cc
@@ -76,21 +76,30 @@ along with GCC; see the file COPYING3.  If not see
      standalone symbol, or a clone of a function that is inlined into another
      function.
 
-   Phase 2: Early inline + value profile transformation.
-     Early inline uses autofdo_source_profile to find if a callsite is:
+   Phase 2: AFDO inline + value profile transformation.
+     This happens during early optimization.
+     During early inlning AFDO inliner is executed which
+     uses autofdo_source_profile to find if a callsite is:
         * inlined in the profiled binary.
         * callee body is hot in the profiling run.
      If both condition satisfies, early inline will inline the callsite
      regardless of the code growth.
-     Phase 2 is an iterative process. During each iteration, we also check
-     if an indirect callsite is promoted and inlined in the profiling run.
-     If yes, vpt will happen to force promote it and in the next iteration,
-     einline will inline the promoted callsite in the next iteration.
+
+     Performing this early has benefit of doing early optimizations
+     before read IPA passe and getting more "context sensitivity" of
+     the profile read.  Profile of inlined functions may differ
+     significantly form one inline instance to another and from the
+     offline version.
+
+     This is controlled by -fauto-profile-inlinig and is independent
+     of -fearly-inlining.
 
    Phase 3: Annotate control flow graph.
      AutoFDO uses a separate pass to:
         * Annotate basic block count
         * Estimate branch probability
+       * Use earlier static profile to fill in the gaps
+         if AFDO profile is ambigous
 
    After the above 3 phases, all profile is readily annotated on the GCC IR.
    AutoFDO tries to reuse all FDO infrastructure as much as possible to make
@@ -2217,18 +2226,6 @@ afdo_annotate_cfg (void)
   free_dominance_info (CDI_POST_DOMINATORS);
 }
 
-/* Wrapper function to invoke early inliner.  */
-
-static unsigned int
-early_inline ()
-{
-  compute_fn_summary (cgraph_node::get (current_function_decl), true);
-  unsigned int todo = early_inliner (cfun);
-  if (todo & TODO_update_ssa_any)
-    update_ssa (TODO_update_ssa);
-  return todo;
-}
-
 /* Use AutoFDO profile to annoate the control flow graph.
    Return the todo flag.  */
 
@@ -2254,15 +2251,9 @@ auto_profile (void)
 
     push_cfun (DECL_STRUCT_FUNCTION (node->decl));
 
-    unsigned int todo = early_inline ();
     autofdo::afdo_annotate_cfg ();
     compute_function_frequency ();
 
-    /* Local pure-const may imply need to fixup the cfg.  */
-    todo |= execute_fixup_cfg ();
-    if (todo & TODO_cleanup_cfg)
-      cleanup_tree_cfg ();
-
     free_dominance_info (CDI_DOMINATORS);
     free_dominance_info (CDI_POST_DOMINATORS);
     cgraph_edge::rebuild_edges ();