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

Hi David,

Thanks for your comments!
I just want to add that I think it would neat if the entry values could map into
multi-location dbg.values and DBG_VALUEs that are being proposed on this list.

For example, if we have:

  int local = param1 + param2 + 123;

I think it would be good if we would be able to to represent the four different
permutations of the values of the parameters being available in the function or
as entry values.

I have not yet delved into the discussion about the multi-location debug values,
so I don't have any proposals for how that could look.
I guess it can (somehow) be mapped into that.  It is clear to me that the usage
of the DBG_VALUE_LIST will be appropriate for the "Salvage Debug
Info", but the idea of using the entry values on IR level is more general
(not very localized), and there is the cause of potential complexity, since we
need to carry that info throughout IR and use it as a backup.

Best regards,
Djordje
________________________________
From: David Stenberg <david.stenberg at ericsson.com>
Sent: Tuesday, September 1, 2020 11:38 AM
To: Djordje Todorovic <Djordje.Todorovic at syrmia.com>; llvm-dev at
lists.llvm.org <llvm-dev at lists.llvm.org>
Cc: paul.robinson at sony.com <paul.robinson at sony.com>; asowda at
cisco.com <asowda at cisco.com>; jeremy.morse at sony.com <jeremy.morse
at sony.com>; ibaev at cisco.com <ibaev at cisco.com>; vsk at apple.com
<vsk at apple.com>; aprantl at apple.com <aprantl at apple.com>;
Petar Jovanovic <petar.jovanovic at syrmia.com>; Nikola Tesic
<Nikola.Tesic at syrmia.com>; dblaikie at gmail.com <dblaikie at
gmail.com>
Subject: Re: [llvm-dev] [RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR

Hi!

On Tue, 2020-09-01 at 07:35 +0000, Djordje Todorovic
wrote:
> Hi all,
>
> The debug entry values feature introduces new DWARF symbols (tags,
attributes,
> operations) on caller (call site) as well as on callee side; and the
intention
> is to improve debugging user experience by using the functionality
(especially
> in “optimized” code by turning “<optimized_out>” values into real
values). The
> call site information includes info about call itself (described with
> DW_TAG_call_site) with corresponding children representing function
arguments
> at the call site (described with DW_TAG_call_site_params). The most
interesting
> DWARF attribute for us (here) is DW_AT_call_value which contains a DWARF
> expression which represents a value of the parameter at the time of the
call.
> For the context of this RFC, more relevant part of the feature is the
callee
> side, and it refers to new DWARF operation - DW_OP_entry_value, used to
> indicate that in some situations we can use parameter’s entry value as a
real
> value in the current frame. It relies on the call-site info provided, and
the
> more DW_AT_call_value generated, the more debug location inputs using
> DW_OP_entry_value will be turned into real values.
>
> Current implementation in LLVM
>
> Currently in LLVM, we generate the DW_OP_entry_values *only* for unmodified
> parameters during the LiveDebugValues pass, for the places where the Code
> Generation truncated live range of the parameters. The potential of the
> functionality goes beyond this, and it means we should be able to use the
entry
> values even for modified parameters iff the modification could be expressed
in
> terms of its entry value. In addition, there are cases where we can express
> values of local variables in terms of some parameter’s entry-values (e.g.
int
> local = param + 2;).
>
> Proposal
>
> The idea of this RFC is to introduce an idea/discussion of using the
> DW_OP_entry_value not only at the end of LLVM pipeline (within
> LiveDebugValues). There are cases it could be useful at IR level; i.e. for
> unused arguments (please take a look into
>
https://protect2.fireeye.com/v1/url?k=16c671b9-4876ec21-16c63122-861fcb972bfc-e4488a7f57de3412&q=1&e=4f293e8b-6a1f-4a80-9de1-30399c7295a6&u=https%3A%2F%2Freviews.llvm.org%2FD85012
> ); I believe there are a lot of cases where an IR pass drops/cuts
variable’s
> debug value info where an entry value can fall back on as a backup
location.
> There could be multiple ways of implementation, but in general, we need to
> extend metadata describing the debug value to support/refer to entry
> value/backup value as well (and when primary location is lost, the value
with
> DW_OP_entry_value becomes the primary one). One way could be extending of
> llvm.dbg.value with an additional operand as following:
>
>                llvm.dbg.value(…, DIEntryValExpression(DW_OP_uconst, 5)) //
> DIEntryValExpression implicitly contains DW_OP_entry_value operation
>
> The bottom line is that the production of call-site side of the feature
stays
> the same, but LLVM will have more freedom to generate more of
> DW_OP_entry_values operation on the callee side.
>
> Any thoughts on this?
I just want to add that I think it would neat if the entry values could map into
multi-location dbg.values and DBG_VALUEs that are being proposed on this list.

For example, if we have:

  int local = param1 + param2 + 123;

I think it would be good if we would be able to to represent the four different
permutations of the values of the parameters being available in the function or
as entry values.

I have not yet delved into the discussion about the multi-location debug values,
so I don't have any proposals for how that could look.

Best regards,
David
> Best regards,
> Djordje
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200901/c039ad28/attachment-0001.html>

Hi,

If we consider simple test case:

void f1(int);
void f2(int i) {
  f1(1);
  i = i + 5;
  f1(3);
}

we can see what are the benefits we get after enabling the DW_OP_entry_value on
IR. Please consider looking at https://reviews.llvm.org/D87233 for more details.
On a very high level, we introduce a utility within Transforms/Utils/Local.cpp,
that will inspect the IR by trying to find an entry Value for a DIVariable. By
introducing such utility, we don't need to carry/introduce any additional
info to llvm.dbg.val or DIVariable.
The utility can be used at various places (similar to salvageDebugInfo()) during
the middle-end phase.

Besides this, the https://reviews.llvm.org/D85012 is another usage of
DW_OP_entry_value outside of the LiveDebugValues.

Best,
Djordje
________________________________
From: Djordje Todorovic <Djordje.Todorovic at syrmia.com>
Sent: Tuesday, September 1, 2020 3:54 PM
To: David Stenberg <david.stenberg at ericsson.com>; llvm-dev at
lists.llvm.org <llvm-dev at lists.llvm.org>
Cc: paul.robinson at sony.com <paul.robinson at sony.com>; asowda at
cisco.com <asowda at cisco.com>; jeremy.morse at sony.com <jeremy.morse
at sony.com>; ibaev at cisco.com <ibaev at cisco.com>; vsk at apple.com
<vsk at apple.com>; aprantl at apple.com <aprantl at apple.com>;
Petar Jovanovic <petar.jovanovic at syrmia.com>; Nikola Tesic
<Nikola.Tesic at syrmia.com>; dblaikie at gmail.com <dblaikie at
gmail.com>
Subject: Re: [llvm-dev] [RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR

Hi David,

Thanks for your comments!
I just want to add that I think it would neat if the entry values could map into
multi-location dbg.values and DBG_VALUEs that are being proposed on this list.

For example, if we have:

  int local = param1 + param2 + 123;

I think it would be good if we would be able to to represent the four different
permutations of the values of the parameters being available in the function or
as entry values.

I have not yet delved into the discussion about the multi-location debug values,
so I don't have any proposals for how that could look.
I guess it can (somehow) be mapped into that.  It is clear to me that the usage
of the DBG_VALUE_LIST will be appropriate for the "Salvage Debug
Info", but the idea of using the entry values on IR level is more general
(not very localized), and there is the cause of potential complexity, since we
need to carry that info throughout IR and use it as a backup.

Best regards,
Djordje
________________________________
From: David Stenberg <david.stenberg at ericsson.com>
Sent: Tuesday, September 1, 2020 11:38 AM
To: Djordje Todorovic <Djordje.Todorovic at syrmia.com>; llvm-dev at
lists.llvm.org <llvm-dev at lists.llvm.org>
Cc: paul.robinson at sony.com <paul.robinson at sony.com>; asowda at
cisco.com <asowda at cisco.com>; jeremy.morse at sony.com <jeremy.morse
at sony.com>; ibaev at cisco.com <ibaev at cisco.com>; vsk at apple.com
<vsk at apple.com>; aprantl at apple.com <aprantl at apple.com>;
Petar Jovanovic <petar.jovanovic at syrmia.com>; Nikola Tesic
<Nikola.Tesic at syrmia.com>; dblaikie at gmail.com <dblaikie at
gmail.com>
Subject: Re: [llvm-dev] [RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR

Hi!

On Tue, 2020-09-01 at 07:35 +0000, Djordje Todorovic
wrote:
> Hi all,
>
> The debug entry values feature introduces new DWARF symbols (tags,
attributes,
> operations) on caller (call site) as well as on callee side; and the
intention
> is to improve debugging user experience by using the functionality
(especially
> in “optimized” code by turning “<optimized_out>” values into real
values). The
> call site information includes info about call itself (described with
> DW_TAG_call_site) with corresponding children representing function
arguments
> at the call site (described with DW_TAG_call_site_params). The most
interesting
> DWARF attribute for us (here) is DW_AT_call_value which contains a DWARF
> expression which represents a value of the parameter at the time of the
call.
> For the context of this RFC, more relevant part of the feature is the
callee
> side, and it refers to new DWARF operation - DW_OP_entry_value, used to
> indicate that in some situations we can use parameter’s entry value as a
real
> value in the current frame. It relies on the call-site info provided, and
the
> more DW_AT_call_value generated, the more debug location inputs using
> DW_OP_entry_value will be turned into real values.
>
> Current implementation in LLVM
>
> Currently in LLVM, we generate the DW_OP_entry_values *only* for unmodified
> parameters during the LiveDebugValues pass, for the places where the Code
> Generation truncated live range of the parameters. The potential of the
> functionality goes beyond this, and it means we should be able to use the
entry
> values even for modified parameters iff the modification could be expressed
in
> terms of its entry value. In addition, there are cases where we can express
> values of local variables in terms of some parameter’s entry-values (e.g.
int
> local = param + 2;).
>
> Proposal
>
> The idea of this RFC is to introduce an idea/discussion of using the
> DW_OP_entry_value not only at the end of LLVM pipeline (within
> LiveDebugValues). There are cases it could be useful at IR level; i.e. for
> unused arguments (please take a look into
>
https://protect2.fireeye.com/v1/url?k=16c671b9-4876ec21-16c63122-861fcb972bfc-e4488a7f57de3412&q=1&e=4f293e8b-6a1f-4a80-9de1-30399c7295a6&u=https%3A%2F%2Freviews.llvm.org%2FD85012
> ); I believe there are a lot of cases where an IR pass drops/cuts
variable’s
> debug value info where an entry value can fall back on as a backup
location.
> There could be multiple ways of implementation, but in general, we need to
> extend metadata describing the debug value to support/refer to entry
> value/backup value as well (and when primary location is lost, the value
with
> DW_OP_entry_value becomes the primary one). One way could be extending of
> llvm.dbg.value with an additional operand as following:
>
>                llvm.dbg.value(…, DIEntryValExpression(DW_OP_uconst, 5)) //
> DIEntryValExpression implicitly contains DW_OP_entry_value operation
>
> The bottom line is that the production of call-site side of the feature
stays
> the same, but LLVM will have more freedom to generate more of
> DW_OP_entry_values operation on the callee side.
>
> Any thoughts on this?
I just want to add that I think it would neat if the entry values could map into
multi-location dbg.values and DBG_VALUEs that are being proposed on this list.

For example, if we have:

  int local = param1 + param2 + 123;

I think it would be good if we would be able to to represent the four different
permutations of the values of the parameters being available in the function or
as entry values.

I have not yet delved into the discussion about the multi-location debug values,
so I don't have any proposals for how that could look.

Best regards,
David
> Best regards,
> Djordje
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200907/e8efed2b/attachment.html>

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