<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 3, 2015 at 11:33 AM, Matt Arsenault <span dir="ltr"><<a 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"><div><div class="h5">
<div>On 08/03/2015 11:27 AM, David Blaikie
wrote:<br>
</div>
<blockquote type="cite">
<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 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>
<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 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 name="14ef4d6e7b3ed79e_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><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></div></div>
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></div></blockquote><div><br></div><div>Somewhat, yes - but it's vaguely important to implementing this the right way in LLVM.<br><br>Why is this a showstopper to the OpenCL debugger? I would imagine if it's purely just for printing things to the user that it's not exactly critical (it doesn't make a program undebuggable). So I assume the debugger is actually using the address space to make choices about how to access things/print them/etc - in which case it seems appropriate to encode the address space of the actual variable (if it's been optimized, moved, etc - as the (hypothetical/future) examples you gave). & I'd imagine, if a variable can be optimized into a different address space in some circumstances, it seems plausible that it could be in different address spaces at different times, potentially - so looking at the address space of the actual variable value being described (& perhaps there's a DWARF encoding for address space in the DWARF location expression syntax, so it can be described on a per-location basis) would be the right choice.<br><br>But of course I know epsilon about any of this.<br><br>- Dave</div><div> </div></div><br></div></div>