<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<div style="margin: 0px; font-size: 12pt; font-family: Calibri, Arial, Helvetica, sans-serif">
Hi David,</div>
<div style="margin: 0px; font-size: 12pt; font-family: Calibri, Arial, Helvetica, sans-serif">
<br>
</div>
<div style="margin: 0px; font-size: 12pt; font-family: Calibri, Arial, Helvetica, sans-serif">
Thanks for your feedback.</div>
<div style="margin: 0px; font-size: 12pt; font-family: Calibri, Arial, Helvetica, sans-serif">
<br>
</div>
<blockquote style="border-left: 3px solid rgb(200, 200, 200); border-top-color: rgb(200, 200, 200); border-right-color: rgb(200, 200, 200); border-bottom-color: rgb(200, 200, 200); padding-left: 1ex; margin-left: 0.8ex; color: rgb(102, 102, 102);">
<div style="margin: 0px; font-size: 12pt; font-family: Calibri, Arial, Helvetica, sans-serif">
<span style="margin: 0px; font-size: 15px; font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; color: rgb(32, 31, 30); background-color: rgb(255, 255, 255); display: inline !important">My
 thinking would be that dbg.values for variable locations, and dbg.values for "backup" entry_value locations would be basically separate - as though there were two variables. How this would be reflected in the IR, I'm not sure - maybe it's similar to what you're
 suggesting (perhaps you could show a more fleshed out example? even for a simple function "void f1(int i) { f2(); f3(i); f2(); }" or something. I guess I would've imagined maybe a way for the dbg.value to include an extra bit saying "I'm an entry value expression"
 - oh, but I see, there's no IR for it how to have an entry value ins the expression? Fair enough, yeah, either using just DW_OP_entry_value with a counted value being the function parameter, or some DWOP_LLVM_* with some more suitable semantics, sounds OK
 to me. But probably having a top-level bit on the dbg.value saying "this is a backup/entry_value based location" is probably useful too - mostly ignored by optimizations, they would apply all the same transformations to it to create new locations from old
 ones, etc.</span></div>
</blockquote>
<div style="margin: 0px; font-size: 12pt; font-family: Calibri, Arial, Helvetica, sans-serif">
We have an LLVM-internal operation (DW_OP_LLVM_entry_value), but I think we might be needing something different/more complex (e.g. a flag that indicates it is an entry_value/backup; since it needs to coexist with the real value). An alternative could be a
 separate intrinsic llvm.dbg.entry_val(), but I think we all want to avoid extra Intrinsics if possible.</div>
<div style="margin: 0px; font-size: 12pt; font-family: Calibri, Arial, Helvetica, sans-serif">
<br style="font-size: 16px; background-color: rgb(255, 255, 255)">
</div>
<blockquote style="border-left: 3px solid rgb(200, 200, 200); border-top-color: rgb(200, 200, 200); border-right-color: rgb(200, 200, 200); border-bottom-color: rgb(200, 200, 200); padding-left: 1ex; margin-left: 0.8ex; color: rgb(102, 102, 102);">
<span style="color: rgb(50, 49, 48); font-family: "Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif; background-color: rgb(255, 255, 255); display: inline !important">I guess it would
 mean a frontend or early pass would create two locations for every parameter? (backup/entry_value based (though that would be tricky to do up-front, since frontends don't do the dataflow analysis, they just create an alloca and let it be read/written to as
 needed - so maybe entry_vaule based locations would be created on the fly more often somehow), and direct)</span><br class="Apple-interchange-newline">
</blockquote>
I guess we'd need something like that, but "on-the-fly" model will be more acceptable. Or, a separate IR pass for that purpose, but it would introduce some extra overhead...</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Best regards,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Djordje</div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> David Blaikie <dblaikie@gmail.com><br>
<b>Sent:</b> Tuesday, September 1, 2020 9:51 AM<br>
<b>To:</b> Djordje Todorovic <Djordje.Todorovic@syrmia.com><br>
<b>Cc:</b> LLVM Dev <llvm-dev@lists.llvm.org>; vsk@apple.com <vsk@apple.com>; aprantl@apple.com <aprantl@apple.com>; david.stenberg@ericsson.com <david.stenberg@ericsson.com>; paul.robinson@sony.com <paul.robinson@sony.com>; Jeremy Morse <jeremy.morse@sony.com>;
 asowda@cisco.com <asowda@cisco.com>; ibaev@cisco.com <ibaev@cisco.com>; Nikola Tesic <Nikola.Tesic@syrmia.com>; Petar Jovanovic <petar.jovanovic@syrmia.com>; Caroline Tice <cmtice@google.com>; Tobias Bosch <tbosch@google.com>; Fangrui Song <maskray@google.com><br>
<b>Subject:</b> Re: [llvm-dev] [RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR</font>
<div> </div>
</div>
<div>
<div dir="ltr">(+ a few other folks from Google interested in increased optimized debug info location nifo)<br>
<br>
I don't have much context for the variable location part of LLVM's DWARF handling - I've mostly been leaving that to other folks, so take anything I say here with a grain of salt.<br>
<br>
My thinking would be that dbg.values for variable locations, and dbg.values for "backup" entry_value locations would be basically separate - as though there were two variables. How this would be reflected in the IR, I'm not sure - maybe it's similar to what
 you're suggesting (perhaps you could show a more fleshed out example? even for a simple function "void f1(int i) { f2(); f3(i); f2(); }" or something. I guess I would've imagined maybe a way for the dbg.value to include an extra bit saying "I'm an entry value
 expression" - oh, but I see, there's no IR for it how to have an entry value ins the expression? Fair enough, yeah, either using just DW_OP_entry_value with a counted value being the function parameter, or some DWOP_LLVM_* with some more suitable semantics,
 sounds OK to me. But probably having a top-level bit on the dbg.value saying "this is a backup/entry_value based location" is probably useful too - mostly ignored by optimizations, they would apply all the same transformations to it to create new locations
 from old ones, etc.<br>
<br>
I guess it would mean a frontend or early pass would create two locations for every parameter? (backup/entry_value based (though that would be tricky to do up-front, since frontends don't do the dataflow analysis, they just create an alloca and let it be read/written
 to as needed - so maybe entry_vaule based locations would be created on the fly more often somehow), and direct)</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Tue, Sep 1, 2020 at 12:35 AM Djordje Todorovic <<a href="mailto:Djordje.Todorovic@syrmia.com">Djordje.Todorovic@syrmia.com</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
Hi all,</p>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
<br>
</p>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
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.<u></u> <u></u></p>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
 <u></u> <u></u></p>
<h1 style="margin:12pt 0in 0.0001pt; line-height:105%; break-after:avoid; font-size:16pt; font-family:"Calibri Light",sans-serif; color:rgb(47,84,150); font-weight:normal">
<span lang="EN-GB" style="color:rgb(0,0,0)">Current implementation in LLVM</span></h1>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
 </p>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
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
<span style="font-size:11pt; font-family:Calibri,sans-serif">beyond </span>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;).<u></u> <u></u></p>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
 <u></u> <u></u></p>
<h1 style="margin:12pt 0in 0.0001pt; line-height:105%; break-after:avoid; font-size:16pt; font-family:"Calibri Light",sans-serif; color:rgb(47,84,150); font-weight:normal">
<span lang="EN-GB" style="color:rgb(0,0,0)">Proposal</span></h1>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
 </p>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
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
<a href="https://reviews.llvm.org/D85012" target="_blank">https://reviews.llvm.org/D85012</a>); 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:<u></u> <u></u></p>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
<br>
</p>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
              <i> llvm.dbg.value(…, DIEntryValExpression(DW_OP_uconst, 5)) // DIEntryValExpression implicitly contains DW_OP_entry_value operation<u></u> <u></u></i></p>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
<br>
</p>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
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.<u></u> <u></u></p>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
<u></u><br>
<u></u></p>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
Any thoughts on this?</p>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
<br>
</p>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
Best regards,</p>
<p class="x_MsoNormal" style="margin:0in 0in 0.0001pt; font-size:11pt; font-family:Calibri,sans-serif">
Djordje</p>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>