<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 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi Reid,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks for taking this on, I'm very pleased to see improvements related to debug info for optimized code. (You can cc me on code reviews, although I'm sure
a lot of the patches will be in areas I am not very familiar with.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org]
<b>On Behalf Of </b>Reid Kleckner via llvm-dev<br>
<b>Sent:</b> Tuesday, September 05, 2017 1:00 PM<br>
<b>To:</b> llvm-dev<br>
<b>Subject:</b> [llvm-dev] RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Debug info today handles two cases reasonably well:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1. At -O0, dbg.declare does a good job describing variables that live at some known stack offset<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2. With optimizations, variables promoted to SSA can be described with dbg.value<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This leaves behind a large hole in our optimized debug info: variables that cannot be promoted, typically because they are address-taken. This is
<a href="https://llvm.org/pr34136">https://llvm.org/pr34136</a>, and this RFC is mostly about addressing that.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The status today is that instcombine removes all dbg.declares and heuristically inserts dbg.values where it can identify the value of the variable in question. This prevents us from having misleading debug info, but it throws away information
about the variable’s location in memory.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Part of the reason that instcombine discards dbg.declares is that we can’t mix and match dbg.value with dbg.declare. If the backend sees a dbg.declare, it accepts that information as more reliable and discards all DBG_VALUE instructions
associated with that variable. So, we need something we can mix. We need a way to say, the variable lives in memory *at this program point*, and it might live somewhere else later on. I propose that we introduce DW_OP_LLVM_memory for this purpose, and then
we transition from dbg.declare to dbg.value+DW_OP_LLVM_memory.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Initially I believed that DW_OP_deref was the way to say this with existing DWARF expression opcodes, but I implemented that in
<a href="https://reviews.llvm.org/D37311">https://reviews.llvm.org/D37311</a> and learned more about how DWARF expressions work. When a debugger begins evaluating a DWARF expression, it assumes that the resulting value will be a pointer to the variable in memory.
For a debugger, this makes sense, because debug builds put things in memory and even after optimization many variables must be spilled. Only the special DW_OP_regN and DW_OP_stack_value expression opcodes change the location of the value from memory to register
or stack value.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">LLVM SSA values obviously do not have an address that we can take and they don’t live in registers, so neither the default memory location model nor DW_OP_regN make sense for LLVM’s dbg.value. We could hypothetically repurpose DW_OP_stack_value
to indicate that the SSA value passed to llvm.dbg.value *is* the variable’s value, and if the expression lacks DW_OP_stack_value, it must be a the address of the value. However, that is backwards incompatible and it seems like quite a stretch.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">DW_OP_LLVM_memory would be very similar to DW_OP_stack_value, though. It would only be valid at the end of a DIExpression. The backend will always remove it because the debugger will assume the variable lives in memory unless it is told
otherwise.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For the original problem of improving optimized debug info while avoiding inaccurate information in the presence of dead store elimination, consider this C example:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> int x = 42; // Can DSE<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> dostuff(x); // Can propagate 42<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> x = computation(); // Post-dominates `x = 42` store<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> escape(&x);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We should be able to do this:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> int x; // eliminate `x = 42` store<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> dbg.value(!x, 42, !DIExpression()) // mark x as the constant 42 in debug info<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> dostuff(42); // propagate 42<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> dbg.value(!x, &x, !DIExpression(DW_OP_LLVM_memory)) // x is in memory again<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> x = computation();<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> escape(&x);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Passes that delete stores would be responsible for checking if the store destination is part of an alloca with associated dbg.value instructions. They would emit a new dbg.value instruction for that variable with the stored value, and clone
the dbg.value instruction that puts the variable back in memory before the killing store. If the store is dead because variable lifetime is ending, the second dbg.value is unnecessary.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This will also allow us to fix debug info for px in this example:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> void __attribute__((optnone, noinline)) usevar(int *x) {}<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> int main(int argc, char **argv) {<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> int x = 42;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> int *px = &x;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> usevar(&x);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> if (argc) usevar(px);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> }<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Today, we emit a location for px like `DW_OP_breg7 RSP+12`, which gives it the incorrect value 42. This is because our DBG_VALUE instruction for px’s location uses a frame index, which we assume is in memory. This is not the case, px is
not in memory, it’s value is a stack object pointer.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Please reply if you have any thoughts on this proposal. Adrian and I hashed this out over Bugzilla, IRC, and in person, so it shouldn’t be too surprising. Let me know if you want to be CC’d on the patches.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>