Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(4815)

Issue 4438083: [google]Add support for sampled profile collection

Can't Edit
Can't Publish+Mail
Start Review
Created:
13 years ago by eraman
Modified:
12 years, 1 month ago
Reviewers:
richard.guenther, mikestump, hubicka
CC:
Diego Novillo, davidxl, silvius.rus_gmail.com, gcc-patches_gcc.gnu.org
Base URL:
svn+ssh://gcc.gnu.org/svn/gcc/branches/google/main/
Visibility:
Public.

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+257 lines, -3 lines) Patch
M gcc/common.opt View 1 chunk +4 lines, -0 lines 0 comments Download
M gcc/doc/invoke.texi View 3 chunks +18 lines, -1 line 0 comments Download
M gcc/gcov-io.h View 1 chunk +3 lines, -0 lines 0 comments Download
M gcc/libgcov.c View 4 chunks +27 lines, -2 lines 0 comments Download
M gcc/params.def View 1 chunk +5 lines, -0 lines 0 comments Download
M gcc/profile.h View 1 chunk +6 lines, -0 lines 0 comments Download
M gcc/profile.c View 1 chunk +3 lines, -0 lines 0 comments Download
M gcc/tree-profile.c View 6 chunks +191 lines, -0 lines 0 comments Download

Messages

Total messages: 12
eraman
This patch from Silvius Rus adds support for sampled edge profile collection to reduce instrumentation ...
13 years ago (2011-04-28 23:42:46 UTC) #1
davidxl
+ Honza This patch may be a candidate for trunk as well. This feature not ...
13 years ago (2011-04-28 23:58:44 UTC) #2
silvius.rus_gmail.com
On Thu, Apr 28, 2011 at 4:58 PM, Xinliang David Li <davidxl@google.com> wrote: > > ...
13 years ago (2011-04-29 00:42:09 UTC) #3
mikestump_comcast.net
On Apr 28, 2011, at 4:42 PM, Easwaran Raman wrote: > This patch from Silvius ...
13 years ago (2011-04-29 01:12:15 UTC) #4
davidxl
Please add regression test cases for the feature. Address the comments when available. Ok for ...
13 years ago (2011-04-29 05:03:09 UTC) #5
richard.guenther_gmail.com
On Fri, Apr 29, 2011 at 1:42 AM, Easwaran Raman <eraman@google.com> wrote: > This patch ...
13 years ago (2011-04-29 09:12:59 UTC) #6
silvius.rus_gmail.com
> How is code-size affected with this patch, non-instrumented vs. > regular-instrumented vs. sample-instrumented? I ...
13 years ago (2011-04-29 16:12:19 UTC) #7
eraman
On Fri, Apr 29, 2011 at 9:12 AM, Silvius Rus <silvius.rus@gmail.com> wrote: >> How is ...
13 years ago (2011-04-29 17:47:40 UTC) #8
mikestump_comcast.net
On Apr 29, 2011, at 9:12 AM, Silvius Rus wrote: > When you build with ...
13 years ago (2011-04-29 18:18:27 UTC) #9
hubicka_ucw.cz
Hi, > + Honza > > This patch may be a candidate for trunk as ...
13 years ago (2011-04-29 20:48:52 UTC) #10
eraman
Committed the attached patch to google/main. Will send a patch for trunk soon. On Thu, ...
12 years, 12 months ago (2011-05-04 21:05:57 UTC) #11
eraman
12 years, 1 month ago (2012-03-30 22:20:21 UTC) #12
I want to revive this patch for mainline and have some questions on
Honza's comments.

On Fri, Apr 29, 2011 at 1:48 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>
>> A known limitation is that value profiling is not yet sampled, but it
>> does not seem to cause problems.
>
> For the performance alone, we probably don't need to care that much
> given the fact that we value porfile only relatively expensive operations.
> But if we want to have the turn off/on feature, then i gueess we need to
> guard everything.  It is not much of pain to add the code generating
> conditionals everywhere, after all.

If we sample value profiling instrumentation as well, does it make
sense to use a single counter and rate for all instrumentations. If
not, does the additional complexity (and flags) justify the benefit of
uniformity?

>> > +/* Insert STMT_IF around given sequence of consecutive statements in the
>> > +   same basic block starting with STMT_START, ending with STMT_END.  */
>> > +
>> > +static void
>> > +insert_if_then (gimple stmt_start, gimple stmt_end, gimple stmt_if)
>> > +{
>> > +  gimple_stmt_iterator gsi;
>> > +  basic_block bb_original, bb_before_if, bb_after_if;
>> > +  edge e_if_taken, e_then_join;
>> > +
>> > +  gsi = gsi_for_stmt (stmt_start);
>> > +  gsi_insert_before (&gsi, stmt_if, GSI_SAME_STMT);
>> > +  bb_original = gsi_bb (gsi);
>> > +  e_if_taken = split_block (bb_original, stmt_if);
>> > +  e_if_taken->flags &= ~EDGE_FALLTHRU;
>> > +  e_if_taken->flags |= EDGE_TRUE_VALUE;
>> > +  e_then_join = split_block (e_if_taken->dest, stmt_end);
>> > +  bb_before_if = e_if_taken->src;
>> > +  bb_after_if = e_then_join->dest;
>
> On mainline when we do profile estimation before profiling instrumentaiton,
now,
> you really want to update profile for performance here.
I am not sure I understand this.

>> > +  make_edge (bb_before_if, bb_after_if, EDGE_FALSE_VALUE);
>> > +}
>> > +
>> > +/* Transform:
>> > +
>> > +   ORIGINAL CODE
>> > +
>> > +   Into:
>> > +
>> > +   __gcov_sample_counter++;
>> > +   if (__gcov_sample_counter >= __gcov_sampling_rate)
>> > +     {
>> > +       __gcov_sample_counter = 0;
>> > +       ORIGINAL CODE
>> > +     }
>
> Hmm, I think the probability that internal loop of program will interfere with
> sampling rate is relatively high, but I see it is bit hard to do something
about
> it.  Can we think of some very basic randomization of sampling_rate?

The predominant use case we have for this technique for server
workloads is as follows: Have a high value for __gcov_sampling_rate
(that should probably be named __gcov_sampling_interval)  during
server start up so that it reduces the overhead as well as ensures
that the startup period doesn't pollute the rest of the counters.
After startup, change the sampling interval to a small value (in many
cases, to 1) using the external interface in libgcov.c. In this use
case, randomization doesn't make sense during startup (since we want
to skip profile collection) as well as the steady phase (since the
interval is 1 or a small number).  If you want to have randomization
support, do you have any suggestions for how to make it work with low
sampling intervals?


Thanks,
Easwaran

> Honza
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b