<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-size:10.0pt;
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"><span style="mso-fareast-language:EN-US">Hi Reid,<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 for sharing this. I plan to work on improving debug-info for variables<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">living in memory as my next "project" so I am very interested to hear with what<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">others have to say about "Idea 1".<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">There is one part of the idea that confuses me. You say we could "keep the<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">dbg.declare instructions", but I don't see where dbg.declare instructions - at<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">least with their current semantics - fit into the design if the frontend is<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">emitting dbg.values after every assignment. Could you please expand on this part<br>
a little?<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<br>
<br>
<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"> llvm-dev <llvm-dev-bounces@lists.llvm.org>
<b>On Behalf Of </b>Reid Kleckner via llvm-dev<br>
<b>Sent:</b> 08 October 2020 20:07<br>
<b>To:</b> llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> [llvm-dev] Notes from dbg.value coffee chat<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I chatted with Jeremy Morse, Orlando, and Stephen Tozer at the dev meeting, and wanted to summarize the conversation for our benefit, and to share it with others. I aim to be brief, so I apologize if these notes aren't as helpful as they
could be to folks who weren't present.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Three project ideas, by priority:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1. Address <a href="https://llvm.org/pr34136">https://llvm.org/pr34136</a>, improving quality of variable location info for variables in memory, by getting the frontend to pre-annotate assignments.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2. Prototype "stop points", or statement markers in the instruction stream. Use Dexter or other tools to measure potential improvements in stepping behavior, consider productionizing.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">3. Move all debug info intrinsics out of the instruction stream by adding a new all-powerful instruction (maybe dbg_point, dbg_label?) that essentially multiplexes one llvm::Instruction into multiple debug instructions.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">4. (bonus) Old idea, low-priority: Prototype a mode that models stop points as having side effects. Start the function by escaping all non-temporary local variables. Variable values should be accurate and writable at all statement start
PCs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Idea 1: Local variables in memory<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Have clang emit dbg.value instructions directly after every assignment. We discussed the similarities of this idea to the idea of "Key Instructions" from Caroline Tice's thesis, but I can't claim this idea is totally faithful to it. For
assignments to memory locations that are not local variables (*p = v, this->m = v), replace the local variable metadata argument with the value of the store destination, using ValueAsMetadata. Standard cleanup passes (instcombine, inliner?) should transform
dbg.values with memory destinations that point into an alloca with the corresponding local variable for the alloca. This allows passes that delete stores other than mem2reg (DSE, Instcombine, GVN, anything using MemorySSA) to not worry about producing dbg.values
because they already exist: the frontend has provided them. This was the fundamental reason why lowerDbgDeclare is called in Instcombine, so we can remove that, keep the dbg.declare instructions or something equivalent, and greatly expand the range over which
the variable is known to live in stack memory. Variables which never participate in dead store elimination (hopefully many) are more likely to be entirely described by a memory location, and to not need a DWARF location list. They will be writable as well.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Idea 2: Stop points<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This is an old idea: LLVM used to have stop point intrinsics before it had debug location instruction attachments. Given the new goals around profiling accuracy that we've declared for location information, perhaps we should reconsider
the merits of the old design. A new intrinsic that functions similarly to dbg.value in that it produces no value, remains in the instruction stream, and is not removed by standard dead code elimination should be introduced. Perhaps dbg.stmt. This could be
lowered down to power the .loc is_stmt bit in the DWARF line tables. We could also have a mode where the *only* information used to fill in the line tables comes from these instructions. Some data flow passes would be required to propagate the current location
into blocks during codegen, similar to some of the existing debug value passes.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Idea 3: dbg_point<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
This is a representational change that is mostly meant to make LLVM more efficient. I don't have data, but we believe that runs of dbg.value instructions slow down passes because they must be iterated over during optimization. We also believe that they are
memory inefficient. A new representation would address that by allowing us to coalesce multiple logically distinct dbg.value operations into one llvm::Instruction. This instruction could be extended to contain all types of debug info instuctions: dbg.label,
dbg.value, dbg.declare, dbg.stmt, or anything else. Having just watched the MLIR tutorial, it reminds me of MLIR regions.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Idea 4: Not much to say<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"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That's all, I'm sure there was more that I missed, and these ideas are perhaps a bit hare-brained still, but maybe the wider community will have some input.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Reid<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>