public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Petr Machata <pmachata@redhat.com>,
	       Richard Biener <richard.guenther@gmail.com>,
	       GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PR58315] reset inlined debug vars at return-to point
Date: Fri, 27 Feb 2015 01:46:00 -0000	[thread overview]
Message-ID: <ork2z4yzcr.fsf@livre.home> (raw)
In-Reply-To: <20150226072315.GZ1746@tucnak.redhat.com> (Jakub Jelinek's	message of "Thu, 26 Feb 2015 08:23:15 +0100")

On Feb 26, 2015, Jakub Jelinek <jakub@redhat.com> wrote:

> On Wed, Feb 25, 2015 at 09:01:09PM -0300, Alexandre Oliva wrote:
>> > On Wed, Feb 25, 2015 at 06:17:33PM -0300, Alexandre Oliva wrote:
>> >> My measurements, for a not particularly unusual testcase, showed an
>> >> overall reduction of 63% in compile time, as indicated yesterday.  Now,
>> >> who should bear the burden of collecting evidence to back up the claims
>> >> against the change?  Are those concerns enough to hold it up?
>> 
>> > Can you e.g. run dwlocstat on some larger C++ binaries built without and
>> > with your patch?  I believe dwlocstat is supposed to count only the
>> > instructions where the variables or parameters are in scope, so should be
>> > exactly what we care about here.
>> 
>> Erhm...  I don't think that would cover the case you were worried about,
>> namely inspecting variables of an inlined function while at a statement
>> moved out of the function ranges.
>> 
>> Anyway, I've run dwlocstat and inspected the results.  There is indeed a
>> significant reduction in the coverage, so I looked into that.

> Significant reduction in the coverage should be a red flag.

Ok, I looked into it further, after patching dwlocstat to dump
per-variable per-range coverage/length info, so as to be able to compare
object files more easily.

So far, all the differences I looked at were caused by padding at the
end of BBs, and by jump stmts without line numbers at the end of BBs,
both right after the debug reset stmts the proposed patch introduces.

I'll dig further, because so far I've only looked at a few cases.  I
have to figure out some way to automate the investigation of these
differences, because it has been too time-intensive, and not really
fruitful in terms of finding the scenarios you're concerned with.

The good news is that, looking deeper into cases that appeared to leak
info across loop iterations, I confirmed I was mistaken in yesterday's
analysis.  Phew! :-)

-- 
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

  parent reply	other threads:[~2015-02-27  0: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 [this message]
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
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=ork2z4yzcr.fsf@livre.home \
    --to=aoliva@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=pmachata@redhat.com \
    --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).