llvm dev - Jul 2021 - Call for testing -- new variable location tracking solution

Hi Djordje,

It's great to see that improvement in coverage, particularly when not
all the improvements are landed yet. Note that some substantial
portion of the new locations might be entry values, knowing the
desired values of variables lets us better identify when entry values
can be used,

On Thu, Jul 29, 2021 at 1:40 PM Djordje Todorovic
<Djordje.Todorovic at syrmia.com> wrote:
> The thing I am concerned about is the number of 0% covered variables. It
has increased when using this new feature, and I was wondering if there is any
reason for that. In addition, the number of debug variables generated is
different.
Several things could be going on here, my bet would be that it's
related to D95617 -- unfortunately the different ways that we
represent variables that have been optimised out can have an effect on
the DWARF produced. David points out in this comment [0] that the fix
isn't complete (non-inline functions with abstract origins can
gain/lose variables depending on our internal representation), I took
a look but fixing it wasn't straight forwards (I think subprograms can
acquire abstract origins after they're dwarf-emitted?).

That could explain why there are more zero-percent variables in the
output (different representation leads to different variable count);
however the total number of variables _decreases_, which I wouldn't
expect. If you can get a small reproducer for that I'd really like to
look at it.

[0] https://reviews.llvm.org/D95617#2672839

--
Thanks,
Jeremy

Hi Jeremy,
>That could explain why there are more zero-percent variables in the
output (different representation leads to different variable count);
however the total number of variables _decreases_, which I wouldn't
expect. If you can get a small reproducer for that I'd really like to
look at it.

I'll try to experiment with this next week. Also, the number of call_site
debugging information is different, so it may indicate that the number of call
instrs is different.

Best,
Djordje


________________________________
From: Jeremy Morse <jeremy.morse.llvm at gmail.com>
Sent: Thursday, July 29, 2021 3:19 PM
To: Djordje Todorovic <Djordje.Todorovic at syrmia.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>; Adrian Prantl <aprantl at
apple.com>; Paul Robinson <paul.robinson at sony.com>; Eric Christopher
<echristo at gmail.com>; Jonas Devlieghere <jdevlieghere at
apple.com>; David Blaikie <dblaikie at gmail.com>; Reid Kleckner
<rnk at google.com>; Vedant Kumar <vsk at apple.com>; Cazalet-Hyams,
Orlando <orlando.hyams at sony.com>; Tozer, Stephen <Stephen.Tozer at
sony.com>
Subject: Re: Call for testing -- new variable location tracking solution

Hi Djordje,

It's great to see that improvement in coverage, particularly when not
all the improvements are landed yet. Note that some substantial
portion of the new locations might be entry values, knowing the
desired values of variables lets us better identify when entry values
can be used,

On Thu, Jul 29, 2021 at 1:40 PM Djordje Todorovic
<Djordje.Todorovic at syrmia.com> wrote:
> The thing I am concerned about is the number of 0% covered variables. It
has increased when using this new feature, and I was wondering if there is any
reason for that. In addition, the number of debug variables generated is
different.
Several things could be going on here, my bet would be that it's
related to D95617 -- unfortunately the different ways that we
represent variables that have been optimised out can have an effect on
the DWARF produced. David points out in this comment [0] that the fix
isn't complete (non-inline functions with abstract origins can
gain/lose variables depending on our internal representation), I took
a look but fixing it wasn't straight forwards (I think subprograms can
acquire abstract origins after they're dwarf-emitted?).

That could explain why there are more zero-percent variables in the
output (different representation leads to different variable count);
however the total number of variables _decreases_, which I wouldn't
expect. If you can get a small reproducer for that I'd really like to
look at it.

[0] https://reviews.llvm.org/D95617#2672839

--
Thanks,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210729/f4d4d94b/attachment-0001.html>

> (I think subprograms can
> acquire abstract origins after they're dwarf-emitted?).
I'd hope not...  The out-of-line instance and all inlined instances
should be pointing to the same abstract origin.  If the out-of-line
instance gets emitted first, *maybe* what you suggest can happen,
because we haven't yet noticed there are inline instances?  But 
that's not how the DWARF is supposed to look.
--paulr