<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 08/03/2015 11:27 AM, David Blaikie
wrote:<br>
</div>
<blockquote
cite="mid:CAENS6Et0qivUxAcJCqDw-urm85t3OXKCbercYq9-ubB8UTs2qA@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Aug 3, 2015 at 11:25 AM, Matt
Arsenault <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:Matthew.Arsenault@amd.com" target="_blank">Matthew.Arsenault@amd.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 07/31/2015 10:12 AM, David Blaikie wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Jul 31, 2015 at
9:59 AM, Matt Arsenault <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:Matthew.Arsenault@amd.com"
target="_blank">Matthew.Arsenault@amd.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span>
<div>On 07/31/2015 06:46 AM, Robinson,
Paul wrote:<br>
</div>
<blockquote type="cite">
<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.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr</span></p>
<p class="MsoNormal"><a
moz-do-not-send="true"
name="14ef4cfbe7bfa47e_14ee50e3c103ca21__MailEndCompose"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></a></p>
</blockquote>
</span> It seems like a single attribute
for the debug address space isn't enough
then to describe both.</div>
</blockquote>
<div><br>
</div>
<div>Why do you need to describe the original
address space, rather than only the one
where the value actually resides? What would
the debugger use this information for? Does
this need to be rendered to the user? For
what reason?<br>
</div>
</div>
</div>
</div>
</blockquote>
</span> Yes, it should be shown to the user. It's part
of the variable the source declared, just like the type
name. In OpenCL it has a lot of consequences for how
that variable behaves w.r.t. synchronization issues and
other things. Although this leads me to another question
for the clang component emitting it, whether the source
address space ID as defined by clang should be emitted
for this attribute, or the target mapped address space
ID. Since these all end up as 0 on x86 for example, it
probably should be the clang source ID in that case.<span
class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
(hmm, speaking of which - perhaps this
shouldn't be an attribute on the variable,
but instead part of the DWARF expression
describing the location of the value? If
it's possible that optimizations would put
the value in one location with one address
space at point A, and a different location
in a different address space at point B)</div>
<div> <br>
</div>
</div>
</div>
</div>
</blockquote>
</span> I don't know much about DWARF. I don't think
there's any reason why a value would be duplicated into
two different address spaces.<br>
<br>
I just checked the spec again and the description of
DW_AT_address_class seems vague on what it is meant for.
It says "DW_AT_address_class attribute to describe how
objects having the given pointer or reference type ought
to be dereferenced." which seems to not be describing
what the source looks like.<br>
</div>
</blockquote>
<div><br>
</div>
<div>DWARF is somewhat intentionally vague.<br>
<br>
Let's start here: Why are you implementing this? Do you
have users filing bugs about sub-optimal debugging
behavior? Have you observed same? Does this patch
help/address that behavior?<br>
</div>
<div> </div>
</div>
<br>
</div>
</div>
</blockquote>
I'm upstreaming some of our internal debug info support patches for
AMDIL/HSAIL. This is the most important one, which currently reports
the backend address space ID which in this case happens to have a
1:1 mapping with the source language. Not having the address space
at all in the debug info is a show stopper for the OpenCL debugger.
The question of optimizations changing the address space is a bit of
an academic question at this point since HSAIL does not have any
optimizations at this time that do this.<br>
<br>
</body>
</html>