This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PR58315] reset inlined debug vars at return-to point


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]