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

[Jeremy Morse via llvm-dev]

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

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

--
Thanks,
Jeremy