[llvm-dev] Call for testing -- new variable location tracking solution

[Djordje Todorovic via llvm-dev]

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>