<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 5, 2017 at 4:26 PM, Robinson, Paul <span dir="ltr"><<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>></span> wrote:<span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span><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-US"><div class="gmail-m_-8044190254791631447WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">While I have a really good handle on the DWARF standard, and have done a bunch of work with the type stuff, my understanding of IR mechanics is pretty naïve,
 so I'd appreciate any explanations that help me understand why the following might be really lame.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">In optimized code, for things like the address-taken case, does the alloca survive?  Assuming it does, can we attach the DIVariable metadata to the alloca instead
 of having a separate dbg.declare?  (It has always seemed to me that this would make some things a lot simpler, as you don't have to troll around looking for that other instruction, use-lists aren't special cased for debug info instructions, and probably other
 things.)</span></p></div></div></blockquote><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-US"><div class="gmail-m_-8044190254791631447WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">If a memory-homed variable retains its alloca and the alloca retains its metadata, then it seems like it should be straightforward to produce that memory address
 as the default location for the variable.</span></p></div></div></blockquote><div><br></div><div>I think if I were redesigning LLVM, I would go even further and merge DILocalVariable and alloca. =) Functions should really just have "variables" that live in memory and can be accessed from any basic block. After SSA promotion, if a variable has no uses that require it to live in memory, we simply wouldn't allocate space for it. I definitely don't plan to do that, though.</div><div><br></div><div>In today's LLVM, dbg.declare does serve one useful purpose: it marks the point of declaration of the variable. We can use it to power DW_AT_start_scope, so that users won't see uninitialized variables that are in scope in this example:</div><div>  int x = f();<br></div><div>  // break here, 'info locals' prints a garbage y because it is in scope</div><div>  int y = f();</div><div><br></div><div>If we don't think we'll ever do DW_AT_start_scope, then yes, we could probably use variable attachments instead of dbg.declare. But I think we want to go the other direction and standardize on dbg.value.</div><div> </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-US"><div class="gmail-m_-8044190254791631447WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">And if we're in the habit of looking at metadata on normal instructions for DIVariables instead of having dbg.value instructions, then maybe we don't need dbg.value
 either.</span></p></div></div></blockquote><div><br></div><div>We definitely need something like dbg.value. For variables that can be fully promoted to SSA values, we need dbg.value to record in the debug info that a source-level assignment occurred at this particular program point. mem2reg completely erases the assigning instruction, so we need some kind of placeholder. For variables that cannot be fully promoted, passes like DSE should make an effort to record in the debug info that an assignment occurred even if the store was deleted.</div><div><br></div><div>It's that concept of a "program point" that I don't think we can replace with instruction metadata attachments. Today's LLVM instructions move around too much to represent that.</div><div><br></div><div>Thanks for reading!</div></div></div></div>