[llvm-dev] [DebugInfo] A value-tracking variable location update

[David Blaikie via llvm-dev]

On Fri, Nov 6, 2020 at 11:29 AM Jeremy Morse
<jeremy.morse.llvm at gmail.com> wrote:
>
> Hi David,
>
> On Fri, Nov 6, 2020 at 7:10 PM David Blaikie <dblaikie at gmail.com> wrote:
> > > The first observation: a significant increase in the byte-coverage statistic,
> > > meaning that we're able to track variable locations for longer and across more
> > > code. This was one of the main aims of this work, having better tracking of
> > > the locations that we know. The increase of seven percentage points includes an
> > > additional two percentage points of entry-value locations. If we disable entry
> > > value production then the scope-bytes-covered statistic moves from 59% to 64%,
> >
> > Was this meant to be "from 64% to 59%"?
> > How does that compare to the baseline no-entry-value number?
>
> I guess that was ambiguous: I mean the baseline scope-bytes-covered
> number with no entry values is 59% with LLVM master as it stands
> today. With instruction referencing and no entry values, the
> scope-bytes-covered number rises to 64%.
>
> > Could you give a quick summary of the distinction between "PC ranges
> > covered" and "total availability"?
>
> "total availability" is the percentage of variables in the program
> that have a DW_AT_location attached -- so a measure of how well we
> preserve locations through the whole compiler.
>
> "PC ranges covered" is, for each variable in each lexical scope,
> dividing the number of program text bytes covered by the variable by
> the number of program text bytes in the lexical scope. If a variable
> location covers 10 bytes of a scope that is 20 bytes in size, then
> that's 50% coverage. The headline "PC ranges covered" is the average
> of all variables in the program -- better at measuring how long we can
> track known locations. (Obviously there are upsides and downsides of
> aggregating like this).

Hmm, at least to me "total availability"... oh - % of variables with
full scope coverage. I see. That seems like a less helpful stat, to me
at least, than PC ranges covered - treating locations as binary
(either fully covered or "as good as not covered at all") seems likely
to undervalue gains in coverage if they don't lead to variables that
have full scope coverage. (I guess it probably works out in the wash
though - that general gains in coverage are evenly distributed and
cause some variables to go from partial to total coverage)

> > > For the dropped locations:
> > >  * 8 false locations are dropped, they used to refer to the wrong value because
> > >    of a failure in register coalescing, see the body of [3].
> >
> > Would these issues ^ show up/be testable with Dexter?
>
> Yes, although it's so deep in the compiler that it'd be tricky to
> write a test that always hit that problem.

Yeah, fair.