<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1250">
<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="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt">
<blockquote style="border-color: rgb(200, 200, 200); border-left: 3px solid rgb(200, 200, 200); padding-left: 1ex; margin-left: 0.8ex; color: rgb(102, 102, 102)">
What would it look like without this extension? If we modeled it as if all the register values were already on the stack (an extension of the current way where the singular value is modeled as being already on the stack, if I understand it correctly?)?<br>
<br>
<div>If it's decided that the best approach is to introduce something like DW_OP_LLVM_register - might be worth migrating to that first (basically adding DW_OP_LLVM_register(0) at the start of every DIExpression) and then expanding it from unary to n-ary support</div>
</blockquote>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt">
Putting the register values initially on the stack reduces the verbosity, though it could complicate successive salvages of variadic DIExpressions - if any value other than the last needs salvaging, then you have to use DWARF stack operations to move it to
the top of the stack. For example, if the elements are pushed in order so that the last element is on the top of the stack:</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt">
<span><br>
</span>
<div><span style="font-family: Consolas, Courier, monospace">%c = mul 3, %a</span><br>
</div>
<div><span style="font-family: Consolas, Courier, monospace">%d = add 5, %b</span><br>
</div>
<div><span style="font-family: Consolas, Courier, monospace">dbg.value(!DILocalVariable("x"), !DIExpression(DW_OP_plus), %c, %d)</span><br>
</div>
<div><span style="font-family: Consolas, Courier, monospace">; Salvage %d</span><br>
</div>
<div><span style="font-family: Consolas, Courier, monospace">dbg.value(!DILocalVariable("x"), !DIExpression(DW_OP_plus_constu, 5, DW_OP_plus), %c, %b)</span><br>
</div>
<div><span style="font-family: Consolas, Courier, monospace">; Salvage %c needs to use DW_OP_swap</span><br>
</div>
<span style="font-family: Consolas, Courier, monospace">dbg.value(!DILocalVariable("x"), !DIExpression(DW_OP_plus_constu, 5, DW_OP_swap, DW_OP_constu, 3, DW_OP_mul, DW_OP_plus), %a, %b)</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt">
<span style="font-family: Consolas, Courier, monospace"><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt">
<span style="font-family: Consolas, Courier, monospace">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif"><span></span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif"><span>Or, written out as the stack state:<br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif"><span style="font-family: Consolas, Courier, monospace">[%a, %b]
<span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span>
</span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span>; Initial state</span><span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif"><span style="font-family: Consolas, Courier, monospace">[%a, %b + 5]
<span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span>
</span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span>;
</span><span><span style="font-family: Consolas, Courier, monospace">DW_OP_plus_constu, 5</span><span style="font-family: Consolas, Courier, monospace">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif"><span style="font-family: Consolas, Courier, monospace">[%b + 5, %a]
<span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span>
</span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span>;
</span><span><span style="font-family: Consolas, Courier, monospace">DW_OP_swap<span><span><span></span><span>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif"><span style="font-family: Consolas, Courier, monospace">[%b + 5, %a, 3]
<span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span><span>
</span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span>;
</span><span><span style="font-family: Consolas, Courier, monospace">DW_OP_constu, 3<span><span><span><span><span><span><span><span></span><span>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif"><span style="font-family: Consolas, Courier, monospace">[%b + 5, %a * 3] ; DW_OP_mul<span><span><span><span><span><span><span><span></span><span>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif"><span style="font-family: Consolas, Courier, monospace">[(%b + 5) + (%a * 3)] ;
</span><span><span style="font-family: Consolas, Courier, monospace">DW_OP_plus<br>
</span></span></div>
</span></span></span></span></span></span></span></span></span><span><span style="font-family: Consolas, Courier, monospace"></span></span></div>
</span></span></span></span></span></span></span></span><br>
</span></span></div>
</span></span></span></span></span></div>
</span></span></div>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt">
<span>The simplest and most general solution would be to use DW_OP_pick, which duplicates the stack element at a given index to the top of the stack. This is more or less the same as using DW_OP_LLVM_register - both of them take an index corresponding to a
register value - with a few differences: we get to maintain the default concise dbg.value with a single argument and empty DIExpression, but salvaging becomes more brittle. If we rely on elements being on the stack in their declared order, then we need to
guarantee that nothing modifies those stack elements. The cleanest implementation of this would be for SalvageDebugInfo to salvage expressions normally when the last register is salvaged, and switch to using DW_OP_pick for every register whenever any other
register is salvaged:<br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt">
<span>
<div><span style="font-family: Consolas, Courier, monospace"></span>
<div><br>
<span style="font-family: Consolas, Courier, monospace"></span></div>
<span style="font-family: Consolas, Courier, monospace">%c = add %a, 5<br>
</span></div>
<div><span style="font-family: Consolas, Courier, monospace">%e = div %c, %d<br>
</span>
<div><span style="font-family: Consolas, Courier, monospace"><span>
<div><span><span><span style="font-family: Consolas, Courier, monospace">; x = %b * ((%a + 5) / %d)</span></span></span></div>
</span></span></div>
<span><span style="font-family: Consolas, Courier, monospace">dbg.value(!DILocalVariable("x"), !DIExpression(DW_OP_mul), %b, %e)</span></span></div>
<div><span><span style="font-family: Consolas, Courier, monospace">; Salvage %e; last operator so salvage normally<span>
<div><span style="font-family: Consolas, Courier, monospace"><span>
<div><span><span><span></span></span></span></div>
</span></span></div>
<span><span style="font-family: Consolas, Courier, monospace">dbg.value(!DILocalVariable("x"), !DIExpression(DW_OP_mul, DW_OP_div), %b, %c, %d)</span></span></span></span></span></div>
<div><span><span style="font-family: Consolas, Courier, monospace">; Salvage %c; not last operator and expression isn't already using pick, so add DW_OP_pick for registers<br>
<span>
<div><span style="font-family: Consolas, Courier, monospace"></span></div>
<span><span style="font-family: Consolas, Courier, monospace">dbg.value(!DILocalVariable("x"), !DIExpression(DW_OP_pick, 0, DW_OP_pick, 1, DW_OP_plus_constu, 5, DW_OP_pick, 2, DW_OP_div, DW_OP_mul), %b, %a, %d)</span></span></span></span></span><br>
<span></span></div>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt">
<span>The major advantage of putting all registers on the stack is that it reduces verbosity and also doesn't require us to implement the new operator or update existing DIExpressions to contain it, which is useful.
<span>Personally I lean towards keeping things simple and consistent, and so using the pick/register operator in every expression rather than only the ones that need it, but there's a good case for either I think.</span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt">
<span></span></div>
<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> David Blaikie <dblaikie@gmail.com><br>
<b>Sent:</b> 20 February 2020 20:21<br>
<b>To:</b> Tozer, Stephen <stephen.tozer@sony.com>; Adrian Prantl <aprantl@apple.com>; Jonas Devlieghere <jdevlieghere@apple.com>; Robinson, Paul <paul.robinson@sony.com>; Eric Christopher <echristo@gmail.com><br>
<b>Cc:</b> llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Allowing debug intrinsics to reference multiple SSA Values</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr">(+usual debug info folks)<br>
<br>
I'm mostly staying out of discussions around optimized debug info/variable locations - other folks have more state on this than I do. But some casual thoughts from the peanut gallery... </div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Thu, Feb 20, 2020 at 8:54 AM Tozer, Stephen via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</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 lang="EN-GB">
<div class="x_gmail-m_1367493516059879895WordSection1">
<p class="x_MsoNormal">Currently, the debug intrinsic functions each have 3 arguments: an SSA value representing either the address or Value of a local variable, a DILocalVariable, and a complex expression. If the SSA value is an Instruction, and that Instruction
is at some point deleted, we attempt to salvage the SSA value by recreating the instruction within the complex expression. If the instruction cannot be replicated by a complex expression, then the variable location is dropped causing a reduction in coverage.
One of the key restrictions on this process at the moment is that each intrinsic can only reference a single SSA value; a numeric constant may be represented within the expression itself, allowing for binary operators with a constant operand to be salvaged:<u></u><u></u></p>
<p class="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">%c = add i32 %a, 4<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">llvm.dbg.value(metadata i32 %c, DILocalVariable("x"), DIExpression())<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">; Salvage...<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">llvm.dbg.value(metadata i32 %a, DILocalVariable("x"), DIExpression(DW_OP_constu, 4, DW_OP_plus))<u></u><u></u></span></p>
<p class="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal">This proposal is to allow multiple SSA value references within a debug intrinsic, allowing binary operators with non-constant operands to be salvaged. This is a long-awaited feature, with an open bugzilla[0] and support from members of
the community[1][2]. To implement this change, each debug intrinsic will contain a list of SSA values instead of just one, and a new operator will be added:
<span style="font-family:Consolas">DW_OP_LLVM_register</span>, which takes as its only argument the index of an SSA value within the intrinsic’s list, and pushes that SSA value onto the expression stack.</p>
</div>
</div>
</blockquote>
<div><br>
What would it look like without this extension? If we modeled it as if all the register values were already on the stack (an extension of the current way where the singular value is modeled as being already on the stack, if I understand it correctly?)?<br>
<br>
If it's decided that the best approach is to introduce something like DW_OP_LLVM_register - might be worth migrating to that first (basically adding DW_OP_LLVM_register(0) at the start of every DIExpression) and then expanding it from unary to n-ary support.<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 lang="EN-GB">
<div class="x_gmail-m_1367493516059879895WordSection1">
<p class="x_MsoNormal">Two proposed syntaxes for the list of SSA values - though suitable alternatives may be worth considering - are to either replace the first argument of the intrinsic function with an MDNode containing the SSA values as operands, or to
remove the first argument and make the intrinsic function variadic, passing the SSA value list as vargs:<u></u><u></u></p>
<p class="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">%c = add i32 %a, %b<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">llvm.dbg.value(metadata i32 %c, DILocalVariable("x"), DIExpression())<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">; Salvage...<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">llvm.dbg.value(!{metadata i32 %a, metadata i32 %b}, DILocalVariable("x"), DIExpression(DW_OP_LLVM_register, 0, DW_OP_LLVM_register, 1, DW_OP_plus))<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">; Alternatively, the intrinsic function could be made variadic...<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">llvm.dbg.value(DILocalVariable("x"), DIExpression(DW_OP_LLVM_register, 0, DW_OP_LLVM_register, 1, DW_OP_plus), metadata i32 %a, metadata i32 %b)<u></u><u></u></span></p>
<p class="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal">The new operator <span style="font-family:Consolas">DW_OP_LLVM_register</span> would exist in the IR and MIR, and further down the pipeline be replaced by the appropriate operator for the target debug output. For example, when producing
DWARF this would be replaced by <span style="font-family:Consolas">DW_OP_regval_type</span>, which pushes the contents of a given register interpreted as a value of a given type onto the DWARF expression stack.<u></u><u></u></p>
<p class="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal">This has the potential to allow salvaging in a much greater number of cases than is currently possible. There are also potential follow-up tasks, such as allowing the salvaging of conditional values, that would further improve debug variable
availability. The following table gives, for several of the multi-source application projects in the test suite, the number of successful invocations of SalvageDebugInfo, and the number of failed salvages for each type of unsalvageable instruction:<u></u><u></u></p>
<p class="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal"><span style="font-family:Consolas"> Success Variadic Binops Variadic GEPs Cmp Insts Select Insts Load Insts Phi Nodes Alloca Insts Call Insts<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">ALAC 261 29 61 0 0 1 12 0 0<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">Burg 50 1 9 0 1 95 6 0 0<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">hbd 514 16 1 0 3 45 10 0 4<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">Lua 270 12 54 0 12 46 32 1 0<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">minisat 458 10 10 3 1 35 4 0 0<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">sgefa 439 1 121 0 20 14 55 0 0<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">SIBsim4 153 15 6 0 3 40 3 0 0<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">siod 112 2 1 0 0 11 5 2 1<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">SPASS 1241 70 27 27 27 2114 156 0 7<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">spiff 39 0 15 0 0 7 2 1 0<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">sqlite3 2322 94 167 6 37 1143 136 4 10<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">treecc 127 1 0 0 1 350 37 0 1<u></u><u></u></span></p>
<p class="x_MsoNormal"><span style="font-family:Consolas">viterbi 7 0 1 0 1 1 0 0 0<u></u><u></u></span></p>
<p class="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal">Of these categories, the first 3 will become salvageable after this work is implemented, and Select Insts will also be salvageable with some follow-up work to enable conditional branching in complex expressions. The remainder are not
salvageable in general, although it's possible that the specific passes that delete those instructions may be able to preserve the debug info as long as the code isn't totally dead.<u></u><u></u></p>
<p class="x_MsoNormal"><u></u> <u></u></p>
<p class="x_MsoNormal">[0] <a href="https://bugs.llvm.org/show_bug.cgi?id=39141" target="_blank">
https://bugs.llvm.org/show_bug.cgi?id=39141</a><u></u><u></u></p>
<p class="x_MsoNormal">[1] <a href="https://reviews.llvm.org/D51976#1237060" target="_blank">
https://reviews.llvm.org/D51976#1237060</a><u></u><u></u></p>
<p class="x_MsoNormal">[2] <a href="http://lists.llvm.org/pipermail/llvm-dev/2019-November/137021.html" target="_blank">
http://lists.llvm.org/pipermail/llvm-dev/2019-November/137021.html</a><u></u><u></u></p>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</div>
</div>
</body>
</html>