<div dir="ltr"><div dir="ltr">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:<br></div><div class="gmail_quote"><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" style="overflow-wrap: break-word;">
<div class="gmail-m_-7552095938052888345WordSection1">
<p class="MsoNormal"><span>Hi Reid,<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>Thanks for sharing this. I plan to work on improving debug-info for variables<u></u><u></u></span></p>
<p class="MsoNormal"><span>living in memory as my next "project" so I am very interested to hear with what<u></u><u></u></span></p>
<p class="MsoNormal"><span>others have to say about "Idea 1".<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>There is one part of the idea that confuses me. You say we could "keep the<u></u><u></u></span></p>
<p class="MsoNormal"><span>dbg.declare instructions", but I don't see where dbg.declare instructions - at<u></u><u></u></span></p>
<p class="MsoNormal"><span>least with their current semantics - fit into the design if the frontend is<u></u><u></u></span></p>
<p class="MsoNormal"><span>emitting dbg.values after every assignment. Could you please expand on this part<br>
a little?</span></p></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div>