Do not recompute profile when entry block has afdo count of 0

With normal profile feedback checking entry block count to be non-zero is quite
reliable check for presence of non-0 profile in the body since the function
body can only be executed if the entry block was executed.  With autofdo this
is not true, since the entry block may just execute too few times to be
recorded.  As a consequence we currently drop AFDO profile quite often.  This
patch fixes it.

gcc/ChangeLog:

	* predict.cc (rebuild_frequencies): look harder for presence
	of profile feedback.

diff --git a/gcc/predict.cc b/gcc/predict.cc
index 16dd9b01112b9973ae7209483962bd9756f88f4f..872f54d957a500251e802512117ca25e79b9f8b7 100644 (file)
--- a/gcc/predict.cc
+++ b/gcc/predict.cc
@@ -4444,11 +4444,14 @@ rebuild_frequencies (void)
   bool inconsistency_found = false;
   bool uninitialized_probablity_found = false;
   bool uninitialized_count_found = false;
+  bool feedback_found = false;
 
   cfun->cfg->count_max = profile_count::uninitialized ();
   FOR_BB_BETWEEN (bb, ENTRY_BLOCK_PTR_FOR_FN (cfun), NULL, next_bb)
     {
       cfun->cfg->count_max = cfun->cfg->count_max.max (bb->count);
+      if (bb->count.nonzero_p () && bb->count.quality () >= AFDO)
+       feedback_found = true;
       /* Uninitialized count may be result of inlining or an omision in an
          optimization pass.  */
       if (!bb->count.initialized_p ())
@@ -4516,8 +4519,7 @@ rebuild_frequencies (void)
      Propagating from probabilities would make profile look consistent, but
      because probablities after code duplication may not be representative
      for a given run, we would only propagate the error further.  */
-  if (ENTRY_BLOCK_PTR_FOR_FN (cfun)->count.ipa ().nonzero_p ()
-      && !uninitialized_count_found)
+  if (feedback_found && !uninitialized_count_found)
     {
       if (dump_file)
        fprintf (dump_file,