public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Sharad Singhai (शरद सिंघई)" <singhai@google.com>
To: Xinliang David Li <davidxl@google.com>
Cc: reply@codereview.appspotmail.com, gcc-patches@gcc.gnu.org
Subject: Re: Disable early inlining while compiling for coverage (issue5173042)
Date: Sat, 01 Oct 2011 05:37:00 -0000	[thread overview]
Message-ID: <CAKxPW644NbjpaiFxNiogOAS8Gxk=yVwh6bora1AvfZmjvCOPfA@mail.gmail.com> (raw)
In-Reply-To: <CAAkRFZKOvbDFa6ke5kDj5kaF1tb1L_3o1pZqZNGFSX1jNWCRag@mail.gmail.com>

Here is an example. In the attached file, foo.c contains only two
functions, 'sum' and 'main'. The function 'sum' gets inlined into
'main' (with -O2).

gcc --coverage -O2 foo.c
./a.out
gcov -b foo.c

Now the coverage data for the 'if' condition in 'sum' looks like this:
(in attached file foo.c.gcov)

        8:    8:    if (v[i]) total += 1;
branch  0 never executed
branch  1 never executed
branch  2 taken 75% (fallthrough)
branch  3 taken 25%

Thus a simple conditional looks like a four-way branch. It is due to
early inlining where a couple of basic blocks get eliminated but the
branch coverage still gets attributed to the conditional. Similarly
the coverage data for the loop in 'sum' looks like this

        9:    7:  for (i = 0; i < N; ++i) {
branch  0 never executed
branch  1 never executed
branch  2 taken 89%
branch  3 taken 11% (fallthrough)

After disabling early inlining, the coverage data looks saner.

Of course, in general, the coverage data cannot be accurate in
presence of optimizations. However, this improves the situation
somewhat and improves usability when compiling without optimization is
not feasible.

Sharad

On Fri, Sep 30, 2011 at 9:15 PM, Xinliang David Li <davidxl@google.com> wrote:
>
> Yes, this will improve test coverage option's usability, but please
> provide the example to explain the issues.
>
> David
>
> On Fri, Sep 30, 2011 at 6:12 PM, Sharad Singhai <singhai@google.com> wrote:
> > This patch disables early inlining when --coverage option is
> > specified. This improves coverage data in presence of other
> > optimizations, specially with -O2 where early inlining changes the
> > control flow graph sufficiently enough to generate seemingly very odd
> > source coverage.
> >
> > Bootstrapped okay and regression tests passed.
> >
> > Okay for google/gcc-4_6?
> >
> > 2011-09-30   Sharad Singhai  <singhai@google.com>
> >
> >        * gcc.c (cc1_options): Added -fno-early-inlining for coverage.
> >
> > Index: gcc.c
> > ===================================================================
> > --- gcc.c       (revision 179402)
> > +++ gcc.c       (working copy)
> > @@ -776,7 +776,7 @@
> >  %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}}\
> >  %{fsyntax-only:-o %j} %{-param*}\
> >  %{fmudflap|fmudflapth:-fno-builtin -fno-merge-constants}\
> > - %{coverage:-fprofile-arcs -ftest-coverage}";
> > + %{coverage:-fprofile-arcs -ftest-coverage -fno-early-inlining}";
> >
> >  /* If an assembler wrapper is used to invoke post-assembly tools
> >    like MAO, --save-temps need to be passed to save the output of
> >
> > --
> > This patch is available for review at http://codereview.appspot.com/5173042
> >

  reply	other threads:[~2011-10-01  5:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-01  1:12 Sharad Singhai
2011-10-01  4:15 ` Xinliang David Li
2011-10-01  5:37   ` Sharad Singhai (शरद सिंघई) [this message]
2011-10-01 12:17   ` Jan Hubicka
2011-10-01 17:19     ` Xinliang David Li
2011-10-01 19:49       ` Sharad Singhai (शरद सिंघई)
2011-10-02 10:04       ` Jan Hubicka
2011-10-02 10:09         ` Jan Hubicka
2011-11-07 21:40           ` Sharad Singhai
2011-11-07 22:16             ` Xinliang David Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKxPW644NbjpaiFxNiogOAS8Gxk=yVwh6bora1AvfZmjvCOPfA@mail.gmail.com' \
    --to=singhai@google.com \
    --cc=davidxl@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=reply@codereview.appspotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).