This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Use working set profile info to determine hotness (issue6852069)
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Teresa Johnson <tejohnson at google dot com>
- Cc: reply at codereview dot appspotmail dot com, hubicka at ucw dot cz, gcc-patches at gcc dot gnu dot org
- Date: Wed, 21 Nov 2012 13:47:30 +0100
- Subject: Re: [PATCH] Use working set profile info to determine hotness (issue6852069)
- References: <20121119224351.C9D2161425@tjsboxrox.mtv.corp.google.com>
> 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);
I think you want to store the minimal count into a global variable to avoid the
repeated working set lookup.
> 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)
And document the parameter.
Honza
> 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