<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.hoenzb
        {mso-style-name:hoenzb;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@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">FYI, Wolfgang has been working on a patch for making LiveDebugValues handle spills and reloads.  Hopefully it will be presentable upstream in the not-too-distant
 future.<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>Adrian Prantl via llvm-dev<br>
<b>Sent:</b> Wednesday, May 11, 2016 2:54 PM<br>
<b>To:</b> Francois Pichet<br>
<b>Cc:</b> llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] [LLVMdev] Improving the quality of debug locations / DbgValueHistoryCalculator<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The most obvious place where it is lacking at the moment is that it only supports DBG_VALUEs in registers. Adding support for constant values, memory locations, and fp constants would be a big win!<o:p></o:p></p>
<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">Adrian<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On May 11, 2016, at 2:52 PM, Francois Pichet <<a href="mailto:pichet2000@gmail.com">pichet2000@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">In retrospect I totally agree with you. I am looking at LiveDebugValue again to see if I can improve certain specific cases.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, May 11, 2016 at 5:14 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On May 11, 2016, at 2:09 PM, Francois Pichet <<a href="mailto:pichet2000@gmail.com" target="_blank">pichet2000@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">Good point.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Currently yes a DEBUG_VALUE "x", vreg0 will be added in BB2. Now I realize this might be wrong in some (corner?) cases where vreg0 no longer refer to "x"<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My fix would be to propagate the DEBUG_VALUE only if "x" is associated with only a single virtual register.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">BTW, my goal is to generally improve DEBUG_VALUE for optimized code, not make it 100% correct.<o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">I hold the (perhaps somewhat extreme) position that having debug info the *may* be correct is worse than having no debug info at all, because it means that — in the end — you then cannot trust *anything* reported by the debugger. (There
 are some debatable corner cases, for example, in contrast to the debugger, the user may know over which path the control flow arrived at the current break point, but these are far in between.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That said, I’m very open to improvements to the quality and correctness, so please don’t feel discouraged :-)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span class="hoenzb"><span style="color:#888888">-- adrian</span></span><br>
<br>
<br>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, May 11, 2016 at 4:43 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
> On May 11, 2016, at 1:12 PM, Francois Pichet <<a href="mailto:pichet2000@gmail.com" target="_blank">pichet2000@gmail.com</a>> wrote:<br>
><br>
> Hello,<br>
><br>
> Regarding the problem of debug range for optimized code.<br>
> Currently a DEBUG_VALUE will be inserted after the <def>vregX<br>
> DEBUG_VALUE are only valid until the end of the current MachineBasicBlock. That's the main problem.<br>
> Why not simply iterate over all uses of vregX and insert an DEBUG_VALUE in all the MachineBasicBlocks where vregX is used. (pre regalloc)<br>
><br>
> I prototyped a small pass to do that and at first it seems to improve .debug_loc range validity and enhance the debugging experience for optimized code.<br>
<br>
The problem that I see with this approach is that DEBUG_VALUEs are only valid until the next DEBUG_VALUE that describes the same variable. How does your pass handle:<br>
<br>
  BB0:<br>
    DEBUG_VALUE “x”, vreg0<br>
<br>
  | |<br>
  | BB1:<br>
  |  DEBUG_VALUE “x”, vreg1<br>
  | |<br>
  \_____BB2:<br>
    |    |<br>
    |____/<br>
  BB2:<br>
    vreg0 // still not clobbered here.<br>
<br>
Does it insert a DEBUG_VALUE “x”, vreg0 into BB2?<br>
<span style="color:#888888"><br>
-- adrian</span><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>