[llvm-dev] [RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR

Tue Sep 8 23:52:37 PDT 2020

Hi Jeremy,

Thanks a lot for your feedback.

For the example in https://reviews.llvm.org/D85012 , I'm not sure that
just using an entry value is correct. The reason why the dbg.values
for arguments are set to undef is not because the value can't be
described, it's because deadargelim changes all the call sites to pass
in 'undef', which I believe makes the value unrecoverable even with
entry values. Can call sites like that be described by DWARF? If so, I
guess a combination of entry-value variable locations and salvaging
the call-site arguments would work.
Using entry-values ('callee' side of the feature) is not enough in any case. It is always connected to the call-site-param (function arguments but we call it call-site-params; 'caller' side of the feature) debug info. I believe that there are call-site-params that could be expressed in terms of DWARF for the cases we face within deadargelim. GCC does perform correct output for both caller and callee sides for unused params.

As you say, we could speculatively produce entry value expressions as
a "backup". I reckon this will work fine, although there'll be some
un-necessary work involved due to it being speculative. I kind of have
a different vision for how this could be done though, and not just for
entry values. It hinges on the instruction referencing variable
location stuff I've been working on: I believe we can use that to
connect variable values at the end of compilation back to LLVM-IR
Values. If that's achievable, we'll have:
 * Information about the set of LLVM-IR Values that are live, and what
physical registers they're in,
 * The IR itself, which contains the target-independent relationships
between Values,
After which we will have enough information at the end of compilation
to directly answer the question "How can we describe this variable
value using only Values that are live?", effectively doing very late
salvaging. We can consider entry values to be always available, and
should be able to recover any value that _can_ be described in terms
of entry values.

That's assuming that the instruction referencing stuff works out. I
can elaborate and give some examples if wanted.
Please share that work when you are ready.

My overarching feeling
is that it'd be great to avoid doing extra working during compilation,
instead leaving things until the end when there's more information
available.
I agree with the statement (it'd be better if possible).

Best,
Djordje

________________________________
From: Jeremy Morse <jeremy.morse.llvm at gmail.com>
Sent: Tuesday, September 8, 2020 2:25 PM
To: Djordje Todorovic <Djordje.Todorovic at syrmia.com>
Cc: David Stenberg <david.stenberg at ericsson.com>; llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Nikola Tesic <Nikola.Tesic at syrmia.com>; Petar Jovanovic <petar.jovanovic at syrmia.com>; ibaev at cisco.com <ibaev at cisco.com>; asowda at cisco.com <asowda at cisco.com>
Subject: Re: [llvm-dev] [RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR

Hi Djordje,

[Late reply as I was away, alas],

For the example in https://reviews.llvm.org/D85012 , I'm not sure that
just using an entry value is correct. The reason why the dbg.values
for arguments are set to undef is not because the value can't be
described, it's because deadargelim changes all the call sites to pass
in 'undef', which I believe makes the value unrecoverable even with
entry values. Can call sites like that be described by DWARF? If so, I
guess a combination of entry-value variable locations and salvaging
the call-site arguments would work.

The isel example in https://reviews.llvm.org/D87233 is good --
although dropping the variable location there is largely because of
SelectionDAGs own limitations rather than the generated code. We can't
describe arguments that aren't used because they're not copied to a
virtual register.

In general, I reckon entry values will be a key part of recovering
variable locations, however I'm not sure that there are many places
where it's truly necessary in LLVM-IR. deadargelim is definitely one
of them; but even then, the Argument remains in the function
signature. We're still able to refer to the Argument in dbg.values, in
program positions where the argument will be available, and where it
will be unavailable. In my opinion, entry values are probably most
useful when things go out of liveness; however we don't know what's in
or out of liveness until the register allocator runs.

As you say, we could speculatively produce entry value expressions as
a "backup". I reckon this will work fine, although there'll be some
un-necessary work involved due to it being speculative. I kind of have
a different vision for how this could be done though, and not just for
entry values. It hinges on the instruction referencing variable
location stuff I've been working on: I believe we can use that to
connect variable values at the end of compilation back to LLVM-IR
Values. If that's achievable, we'll have:
 * Information about the set of LLVM-IR Values that are live, and what
physical registers they're in,
 * The IR itself, which contains the target-independent relationships
between Values,
After which we will have enough information at the end of compilation
to directly answer the question "How can we describe this variable
value using only Values that are live?", effectively doing very late
salvaging. We can consider entry values to be always available, and
should be able to recover any value that _can_ be described in terms
of entry values.

That's assuming that the instruction referencing stuff works out. I
can elaborate and give some examples if wanted. My overarching feeling
is that it'd be great to avoid doing extra working during compilation,
instead leaving things until the end when there's more information
available.

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