public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PR58315] reset inlined debug vars at return-to point
Date: Thu, 05 Mar 2015 19:26:00 -0000	[thread overview]
Message-ID: <ord24n8cul.fsf@livre.home> (raw)
In-Reply-To: <CAFiYyc1YD=GqCJD9V9jz35ZjefHW3mMZbb75PomNeUykaqN=Og@mail.gmail.com>	(Richard Biener's message of "Wed, 4 Mar 2015 16:38:13 +0100")

On Mar  4, 2015, Richard Biener <richard.guenther@gmail.com> wrote:

> Compile-time was slightly faster with the patch, 45s vs. 47s,
> but the machine wasn't completely un-loaded.  var-tracking parts:

> unpatched:

>  variable tracking       :   0.63 ( 1%) usr   0.03 ( 1%) sys   0.82 (
> 2%) wall   28641 kB ( 2%) ggc
>  var-tracking dataflow   :   3.72 ( 8%) usr   0.04 ( 1%) sys   3.65 (
> 7%) wall    1337 kB ( 0%) ggc
>  var-tracking emit       :   2.63 ( 6%) usr   0.02 ( 1%) sys   2.55 (
> 5%) wall  148835 kB ( 8%) ggc

> patched:

>  variable tracking       :   0.64 ( 1%) usr   0.01 ( 0%) sys   0.72 (
> 1%) wall   24202 kB ( 1%) ggc
>  var-tracking dataflow   :   1.96 ( 4%) usr   0.01 ( 0%) sys   1.94 (
> 4%) wall    1326 kB ( 0%) ggc
>  var-tracking emit       :   1.46 ( 3%) usr   0.02 ( 0%) sys   1.49 (
> 3%) wall   46980 kB ( 3%) ggc

> we have at the point of RTL expansion 56% more debug statements
> (988231 lines with # DEBUG in the .optimized dump out of
> 1212518 lines in total vs. 630666 out of 854953).  So we go from
> roughly 1 debug stmt per real stmt to 1.5 debug stmts per real stmt.

So, if I got this right, all these extra debug stmts and insns had no
effect whatsoever on compile time proper.  The reduction in compile time
can be entirely accounted for by the time they save in the var-tracking
parts, and any compile time increase they bring about in other passes is
negligible.

Does this match your assessment of the impact of the patch?


> we have two pairs of DEBUG stmts for dD.570173 here, binding
> to _25 and then immediately resetting.

They're at different lines, and associated with different statements, so
once we have stmt frontiers support in GCC and GDB, you will be able to
stop between them an inspect the state, regardless of the absence of
executable code between them.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

  reply	other threads:[~2015-03-05 19:26 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-25 10:06 Alexandre Oliva
2015-02-25 11:01 ` Richard Biener
2015-02-25 16:28   ` Jakub Jelinek
2015-02-25 21:22     ` Alexandre Oliva
2015-02-25 21:44       ` Jakub Jelinek
2015-02-26  2:16         ` Alexandre Oliva
2015-02-26  7:37           ` Jakub Jelinek
2015-02-26 16:31             ` Petr Machata
2015-02-27  1:46             ` Alexandre Oliva
2015-02-27 10:19               ` Petr Machata
2015-02-27 22:03                 ` Alexandre Oliva
2015-03-06 18:05               ` Alexandre Oliva
2015-03-09 14:38                 ` Richard Biener
2015-03-09 17:17                   ` Jeff Law
2015-03-10 16:35                     ` Alexandre Oliva
2015-02-26 10:46           ` Richard Biener
2015-02-26 10:46             ` Jakub Jelinek
2015-02-26 11:03               ` Richard Biener
2015-02-26 17:13                 ` Alexandre Oliva
2015-02-26 16:55             ` Alexandre Oliva
2015-02-26 17:16           ` Alexandre Oliva
2015-02-25 21:13   ` Alexandre Oliva
2015-03-04 15:38 ` Richard Biener
2015-03-05 19:26   ` Alexandre Oliva [this message]
2015-03-05 20:27     ` Richard Biener
2015-06-03 22:05 ` Alexandre Oliva
2015-06-08  8:03   ` Richard Biener

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=ord24n8cul.fsf@livre.home \
    --to=aoliva@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.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).