<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";
color:black;}
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-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 bgcolor="white" 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">The debug info generally should be mapping the source to the code/data as actually generated, even after optimizations shuffle things around. If the original
code thinks it's allocating something in AS 0 but optimization puts it in AS 3, and the user asks the debugger to display the value, how does the debugger know to look in AS 3? Asking the debugger to troll around looking for an instruction that it might guess
is loading/storing the value and assuming that address is the actual location… seems like asking a bit much.<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";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> llvm-commits-bounces@cs.uiuc.edu [mailto:llvm-commits-bounces@cs.uiuc.edu]
<b>On Behalf Of </b>Matt Arsenault<br>
<b>Sent:</b> Thursday, July 30, 2015 5:39 PM<br>
<b>To:</b> David Blaikie<br>
<b>Cc:</b> reviews+D11635+public+0b7e77dd124b8ed5@reviews.llvm.org; llvm-commits@cs.uiuc.edu<br>
<b>Subject:</b> Re: [PATCH] D11635: DebugInfo: Emit DW_AT_address_class for non-0 address space<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 07/30/2015 01:59 PM, David Blaikie wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Jul 30, 2015 at 1:41 PM, Matt Arsenault <<a href="mailto:Matthew.Arsenault@amd.com" target="_blank">Matthew.Arsenault@amd.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">On 07/30/2015 10:54 AM, David Blaikie wrote:<o:p></o:p></p>
<p class="MsoNormal">If we could rely on the llvm::Value that the debug info variable description points to always having a PointerType with the desired address space, then we could just get it from there & wouldn't need to add more info to the debug info variable
description.<o:p></o:p></p>
<p class="MsoNormal">OK, I see what you mean now. We would like to be able to change the address space of the value for optimization purposes, but still report the source address space. For example, the AMDGPUPromoteAlloca pass now currently tries to replace
allocas in address space 0 with globals in address space 3.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Interesting - what's the debugger going to do with the address space, though? Is it going to need to know the real address space, or the original one?<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>
</blockquote>
<p class="MsoNormal">I would expect the debugger to show the original address space. If it needed to know the address space of the actual load / store, it could look at what machine instruction is being executed.<br>
<br>
I'm trying to add addrSpace as a first class member of DIDerivedType like SizeInBits/AlignInBits, but this seems to require touching more components than I expected. Does this field really need to be added to MDNodeKeyImpl? This seems like a lower level place
than I expected needing to touch. I would expect people would want to avoid adding new fields to things like this to save memory<br>
<br>
-Matt<o:p></o:p></p>
</div>
</div>
</body>
</html>