<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">> I think what I meant is that we need to keep the association between the alloca and the local variable somewhere. The current implementation of dbg.declare is not what we want: when we have one, it overrides any dbg.values, and the alloca
is used as the variable location for the full scope. That's not what we want, but we do need an association between alloca and variable+scope somewhere. The dbg.values in the design as we discussed it would not contain the alloca, but the SSA value which is
stored to the alloca. Maybe if we augmented the dbg.values with the store destination, we could get by without tracking that information separately.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">> The main design goal here was to have the variable location information be correct even when DSE occurs, without updating every pass that deletes stores, because there are many. Thinking about it today, I'm not sure this design is complete
yet. Even if the frontend effectively emits two stores for every assignment, a real store, and dbg.value, the backend needs to determine if the real store survived optimization. If it did, then the variable value lives in memory. If it did not, then the variable
value is the value which would've been stored, if it is available at this program point, or if it is available somewhere nearby. Maybe that's acceptable, but it seems difficult. However, maybe that's similar to what we already do for dbg.values uses that precede
definitions.<span style="mso-fareast-language:EN-US"><br>
<br>
That makes sense, thank you. I had also thought about extending dbg.value to keep the store destination. One step further could be to introduce a mechanism to refer to the store itself instead of the store destination (possibly similar to Jeremy's recent MIR
debug instruction referencing work [1], but for this situation in IR). If the referenced store has been removed (e.g. by DSE) then we know to use the value instead, which may also have been salvaged or be undef at this point. And if the store has not been
removed then we can grab the destination from the store itself.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I'm starting to form the opinion that the ideal solution will provide correctness by default without passes having to do anything, but allow the onus of improving coverage to fall upon those passes.
We've recently taken a turn in this direction in D80264 [2] whereby we now replace an instruction's ValueAsMetadata uses with undef on deletion. This provides correctness by default for debug intrinsics using the instruction, and the coverage may be improved
by a pass appropriately calling salvageDebugInfo beforehand.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><br>
></span> The alternative to this design would be to say that stores to static allocas are special, and cannot be deleted without updating debug info. This is basically
<a href="https://llvm.org/pr34136#c25">https://llvm.org/pr34136#c25</a>. Thinking about it again today, maybe this approach is feasible. We could build tooling to audit for passes that delete these special "assigning stores". Maybe that's better than bending
over backwards just to make it easy for the optimizers.<o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">The "static allocas are special" [3] approach is appealing because it seems like it may give promising results without too much work (compared with these other ideas, anyway). It does rely on passes
to provide debug-info correctness, but tooling may be an appropriate stand in for correctness by default if we decide to go down this route. Did you have anything in mind for this?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Orlando<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">[1] http://lists.llvm.org/pipermail/llvm-dev/2020-February/139440.html<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">[2] https://reviews.llvm.org/D80264<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">[3] <a href="https://llvm.org/pr34136#c25">
https://llvm.org/pr34136#c25</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Reid Kleckner <rnk@google.com>
<br>
<b>Sent:</b> 09 October 2020 19:13<br>
<b>To:</b> Cazalet-Hyams, Orlando <orlando.hyams@sony.com><br>
<b>Cc:</b> llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] Notes from dbg.value coffee chat<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Oct 9, 2020 at 9:38 AM Cazalet-Hyams, Orlando <<a href="mailto:orlando.hyams@sony.com">orlando.hyams@sony.com</a>> wrote:<o:p></o:p></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi Reid,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks for sharing this. I plan to work on improving debug-info for variables<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">living in memory as my next "project" so I am very interested to hear with what<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">others have to say about "Idea 1".<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">There is one part of the idea that confuses me. You say we could "keep the<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">dbg.declare instructions", but I don't see where dbg.declare instructions - at<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">least with their current semantics - fit into the design if the frontend is<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">emitting dbg.values after every assignment. Could you please expand on this part<br>
a little?<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think what I meant is that we need to keep the association between the alloca and the local variable somewhere. The current implementation of dbg.declare is not what we want: when we have one, it overrides any dbg.values, and the alloca
is used as the variable location for the full scope. That's not what we want, but we do need an association between alloca and variable+scope somewhere. The dbg.values in the design as we discussed it would not contain the alloca, but the SSA value which is
stored to the alloca. Maybe if we augmented the dbg.values with the store destination, we could get by without tracking that information separately.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The main design goal here was to have the variable location information be correct even when DSE occurs, without updating every pass that deletes stores, because there are many. Thinking about it today, I'm not sure this design is complete
yet. Even if the frontend effectively emits two stores for every assignment, a real store, and dbg.value, the backend needs to determine if the real store survived optimization. If it did, then the variable value lives in memory. If it did not, then the variable
value is the value which would've been stored, if it is available at this program point, or if it is available somewhere nearby. Maybe that's acceptable, but it seems difficult. However, maybe that's similar to what we already do for dbg.values uses that precede
definitions.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The alternative to this design would be to say that stores to static allocas are special, and cannot be deleted without updating debug info. This is basically
<a href="https://llvm.org/pr34136#c25">https://llvm.org/pr34136#c25</a>. Thinking about it again today, maybe this approach is feasible. We could build tooling to audit for passes that delete these special "assigning stores". Maybe that's better than bending
over backwards just to make it easy for the optimizers.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>