This is the mail archive of the
mailing list for the GCC project.
Re: [PR58315] reset inlined debug vars at return-to point
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Petr Machata <pmachata at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 26 Feb 2015 21:25:40 -0300
- Subject: Re: [PR58315] reset inlined debug vars at return-to point
- Authentication-results: sourceware.org; auth=none
- References: <orlhjm2usl dot fsf at livre dot home> <CAFiYyc1a+cMHKk-dAJ3SbErhDotEGFRekK=xBy+DbHpFpZWE2g at mail dot gmail dot com> <20150225161256 dot GT1746 at tucnak dot redhat dot com> <or7fv53d3m dot fsf at livre dot home> <20150225212231 dot GX1746 at tucnak dot redhat dot com> <ortwy91qyi dot fsf at livre dot home> <20150226072315 dot GZ1746 at tucnak dot redhat dot com>
On Feb 26, 2015, Jakub Jelinek <firstname.lastname@example.org> 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