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]

[PATCH] Use working set profile info to determine hotness (issue6852069)


This patch uses the new working set information from the profile to select
the hot count threshold for an application instead of using a hard cutoff.
Currently the threshold is set by default to the minimum counter value
needed to reach 99.9% of the profiled execution time, but I have added
a parameter to control this.

I saw a couple improvements in SPEC2006 on a Westmere, such as xalancbmk by a few
percent.

Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk?

Thanks,
Teresa


2012-11-19  Teresa Johnson  <tejohnson@google.com>

	* predict.c (maybe_hot_count_p): Use threshold from profiled working
	set instead of hard limit.
	(cgraph_maybe_hot_edge_p): Invoke maybe_hot_count_p() instead of
	directly checking limit.
	* params.def (HOT_BB_COUNT_FRACTION): Remove.
	(HOT_BB_COUNT_WS_PERCENT): New parameter.

Index: predict.c
===================================================================
--- predict.c	(revision 193614)
+++ predict.c	(working copy)
@@ -134,13 +134,15 @@ maybe_hot_frequency_p (struct function *fun, int f
 static inline bool
 maybe_hot_count_p (struct function *fun, gcov_type count)
 {
+  gcov_working_set_t *ws;
   if (profile_status_for_function (fun) != PROFILE_READ)
     return true;
   /* Code executed at most once is not hot.  */
   if (profile_info->runs >= count)
     return false;
-  return (count
-	  > profile_info->sum_max / PARAM_VALUE (HOT_BB_COUNT_FRACTION));
+  ws = find_working_set (PARAM_VALUE (HOT_BB_COUNT_WS_PERCENT));
+  gcc_assert (ws);
+  return (count >= ws->min_counter);
 }
 
 /* Return true in case BB can be CPU intensive and should be optimized
@@ -161,8 +163,8 @@ bool
 cgraph_maybe_hot_edge_p (struct cgraph_edge *edge)
 {
   if (profile_info && flag_branch_probabilities
-      && (edge->count
-	  <= profile_info->sum_max / PARAM_VALUE (HOT_BB_COUNT_FRACTION)))
+      && !maybe_hot_count_p (DECL_STRUCT_FUNCTION (edge->caller->symbol.decl),
+                             edge->count))
     return false;
   if (edge->caller->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
       || (edge->callee
Index: params.def
===================================================================
--- params.def	(revision 193614)
+++ params.def	(working copy)
@@ -365,10 +365,11 @@ DEFPARAM(PARAM_SMS_LOOP_AVERAGE_COUNT_THRESHOLD,
 	 "A threshold on the average loop count considered by the swing modulo scheduler",
 	 0, 0, 0)
 
-DEFPARAM(HOT_BB_COUNT_FRACTION,
-	 "hot-bb-count-fraction",
-	 "Select fraction of the maximal count of repetitions of basic block in program given basic block needs to have to be considered hot",
-	 10000, 0, 0)
+DEFPARAM(HOT_BB_COUNT_WS_PERCENT,
+	 "hot-bb-count-ws-percent",
+         "A basic block profile count is considered hot if it contributes to "
+         "the given percentage (times ten) of the entire profiled execution",
+	 999, 0, 1000)
 DEFPARAM(HOT_BB_FREQUENCY_FRACTION,
 	 "hot-bb-frequency-fraction",
 	 "Select fraction of the maximal frequency of executions of basic block in function given basic block needs to have to be considered hot",
@@ -392,7 +393,7 @@ DEFPARAM (PARAM_ALIGN_LOOP_ITERATIONS,
    flatten the profile.
 
    We need to cut the maximal predicted iterations to large enough iterations
-   so the loop appears important, but safely within HOT_BB_COUNT_FRACTION
+   so the loop appears important, but safely within maximum hotness
    range.  */
 
 DEFPARAM(PARAM_MAX_PREDICTED_ITERATIONS,

--
This patch is available for review at http://codereview.appspot.com/6852069


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