<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">Burying the value/address distinction in an expression opcode makes it pretty inconvenient for code that wants the distinction to make a difference, I would
think. I don't know how often that actually matters though.<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""> David Blaikie [mailto:dblaikie@gmail.com]
<br>
<b>Sent:</b> Monday, September 11, 2017 12:58 PM<br>
<b>To:</b> Reid Kleckner; Adrian Prantl<br>
<b>Cc:</b> Robinson, Paul; llvm-dev; Alex Bradbury; Chandler Carruth<br>
<b>Subject:</b> Re: Unify debug and optimized variable locations with llvm.dbg.addr [was: DW_OP_LLVM_memory]<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Sep 11, 2017 at 12:35 PM Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal">On Fri, Sep 8, 2017 at 10:32 AM, Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">> On Sep 7, 2017, at 2:18 PM, Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<br>
><br>
> On Thu, Sep 7, 2017 at 11:11 AM, Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> wrote:<br>
>> Different intrinsics sounds like a good solution to me. J<br>
>><br>
>> So what happens with the case where a variable is registerized but later we decide to spill it? Presumably we'd have a dbg.addr to point to the spill slot. In past compilers I've used, spill slots were treated analogous to register allocation, i.e. some
effort was made to minimize the number of spill slots and a variable might be spilled to different slots at different points. If LLVM does that, then dbg.addr will have to be allowed to associated different addresses with the variable. On the other hand,
if LLVM allocates a unique memory "home" for each spilled variable, then dbg.addr can retain the property you suggest, that the address expression is always the same.<br>
><br>
> dbg.addr is really IR only. Machine DBG_VALUE instructions can already represent addresses or values depending on their second argument. At this point, I don't see any reason to change that.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">If we can write a verifier to check the validity of a dbg.addr's address, why do we need the separate intrinsic? I guess the answer is that while every address must be a pointer value, not every pointer value is an address. Is this correct?<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Mainly just for readability. We're encoding one bit of information: is the result of DWARF expression on the LLVM value argument the variable's address or value? The DW_OP_LLVM_memory proposal encodes that bit as a special opcode in the
expression. The dbg.addr proposal makes it more first class: it's part of the IR, the intrinsic, not some possibly semantically unimportant metadata. People seem to prefer that.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><br>
People do? I'd actually lean the other way myself (closer to DWARF, fewer first class constructs in the IR/more orthogonality, etc) - FWIW, or in case my other rambling emails were confusing. (well, maybe the intermediate state/mismatch between LLVM IR and
DWARF is enough that it can't be close enough to DWARF to be sensible/tidy, so taking it further away as you're suggesting here might be better).<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>