<div dir="ltr">Great! This seems like a crucial feature for building expressions to represent induction variables, which I am told is an important long standing problem. From your proposed solutions, I like the idea of making dbg.value variadic.<div><br></div><div>In the long run, I think we should consider making llvm.dbg.value a first class IR instruction. My reasons for that mostly have to do with efficiency, which doesn't relate to what you are doing, so I deleted what I wrote on that topic to avoid derailing. I think using a variadic intrinsic is consistent with this long-term design idea, to be discussed further at another time.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 20, 2020 at 8:55 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="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="gmail-m_-9032886397051934770WordSection1">
<p class="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="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-family:Consolas">%c = add i32 %a, 4<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">llvm.dbg.value(metadata i32 %c, DILocalVariable("x"), DIExpression())<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">; Salvage...<u></u><u></u></span></p>
<p class="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="MsoNormal"><u></u> <u></u></p>
<p class="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. 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="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-family:Consolas">%c = add i32 %a, %b<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">llvm.dbg.value(metadata i32 %c, DILocalVariable("x"), DIExpression())<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">; Salvage...<u></u><u></u></span></p>
<p class="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="MsoNormal"><span style="font-family:Consolas">; Alternatively, the intrinsic function could be made variadic...<u></u><u></u></span></p>
<p class="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="MsoNormal"><u></u> <u></u></p>
<p class="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="MsoNormal"><u></u> <u></u></p>
<p class="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="MsoNormal"><u></u> <u></u></p>
<p class="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="MsoNormal"><span style="font-family:Consolas">ALAC        261                 29                  61                  0                   0                   1                   12                  0                   0<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">Burg        50                  1                   9                   0                   1                   95                  6                   0                   0<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">hbd         514                 16                  1                   0                   3                   45                  10                  0                   4<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">Lua         270                 12                  54                  0                   12                  46                  32                  1                   0<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">minisat     458                 10                  10                  3                   1                   35                  4                   0                   0<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">sgefa       439                 1                   121                 0                   20                  14                  55                  0                   0<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">SIBsim4     153                 15                  6                   0                   3                   40                  3                   0                   0<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">siod        112                 2                   1                   0                   0                   11                  5                   2                   1<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">SPASS       1241                70                  27                  27                  27                  2114                156                 0                   7<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">spiff       39                  0                   15                  0                   0                   7                   2                   1                   0<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">sqlite3     2322                94                  167                 6                   37                  1143                136                 4                   10<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">treecc      127                 1                   0                   0                   1                   350                 37                  0                   1<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">viterbi     7                   0                   1                   0                   1                   1                   0                   0                   0<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="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="MsoNormal"><u></u> <u></u></p>
<p class="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="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="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>