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

[Jakub Jelinek <jakub at redhat dot com>]

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.

I admit I haven't read dwlocstat sources recently, but:

dwlocstat
=========

This is a tool for examining Dwarf location info coverage.  It goes
through DIEs of given binary's debug info that represent variables and
function parameters.  For each such DIE, it computes coverage of that
DIE's range (list of addresses of DIE's scope) by location expressions
(a description of where given variable is located at given location:
e.g. a variable can be in a register).

matches what I wanted the tool to do, namely, if you have say some
DW_TAG_variable that is in scope of say an inline function and that
DW_TAG_inlined_subroutine has DW_AT_ranges L1-L2, L3-L4, L5-L6,
it counts on what percentage of bytes in those ranges (or instructions?)
the variable has defined location.
The fear I have is that due to scheduling or any other code motion toward
the end of function, you simply have instructions like L5-L6 above that are
considered part of the function, but that the newly added resets are say on
L4 or so and thus whenever you stop on the L5-L6 instructions, the debugger
will show you you are in the inline function, but you won't be able to
inspect most if not any variables.

> What I found out is that the reduction is an improvement on yet another
> long-standing var-tracking issue: if a function is called within a loop
> and we inline it, bindings from the call in one iteration of the loop
> will carry over onto the subsequent iteration until a new binding
> occurs.  This accounts for all of the coverage reductions I've
> investigated.

It really depends.
Say if you have some
inline void foo (void) { 
  int somevar;
LARGE CODE NOT INITIALIZING somevar;
  somevar = VALUE;
USE somevar;
}
and
for (...)
{
  foo ();
}
and the loop is unrolled, then indeed, lost of coverage between the start of
the second foo and somevar = VALUE; is acceptable, if it previously just
contained the value from previous iteration.  But as I said above, if it is
about the last few stmts in the inline scope, it is undesirable, and if e.g.
the instructions from different unrolled iterations are intermixed, then it
is undesirable too.  Which is why I was suggesting special debug binds that
the optimizers would try to move downward (towards the exit block) on (as
much as possible) any code motions across them, unless the debug binds would
be moved across a debug bind for the same decl - in that case the end of
scope debug bind should be removed rather than moved over.  In most cases,
there won't be much of code motion across the whole function, but only
limited scope, so in the common case you'll still get the effect you are
looking for or close to that, but it won't actually penalize the debug info
quality.

	Jakub