<div dir="ltr">(list switch)<br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">David Blaikie</b> <span dir="ltr"><<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>></span><br>Date: Thu, Aug 20, 2015 at 4:52 PM<br>Subject: Re: [PATCH] D11635: DebugInfo: Emit DW_AT_address_class for non-0 address space<br>To: Matt Arsenault <<a href="mailto:Matthew.Arsenault@amd.com">Matthew.Arsenault@amd.com</a>><br>Cc: "Robinson, Paul" <<a href="mailto:Paul_Robinson@playstation.sony.com">Paul_Robinson@playstation.sony.com</a>>, "<a href="mailto:reviews%2BD11635%2Bpublic%2B0b7e77dd124b8ed5@reviews.llvm.org">reviews+D11635+public+0b7e77dd124b8ed5@reviews.llvm.org</a>" <<a href="mailto:reviews%2BD11635%2Bpublic%2B0b7e77dd124b8ed5@reviews.llvm.org">reviews+D11635+public+0b7e77dd124b8ed5@reviews.llvm.org</a>>, "<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>" <<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>><br><br><br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Aug 10, 2015 at 3:00 PM, 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 08/06/2015 03:59 PM, David Blaikie
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Aug 5, 2015 at 6:36 PM, 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"><span>On 08/03/2015 11:38 AM, David Blaikie wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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 <br>
</blockquote>
</span>
After talking to some debugger people, it seems this is
actually used to read the values and is required to be the
hardware address space value in the end. What does passing
through the actual value look like to emit this? </blockquote>
<div><br>
</div>
<div>Good question.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">DW_AT_address_class
seems to be attached to the type in the spec (although it
apparently can be attached to other things that need it
such as variables and parameters), and not necessarily a
value. We have to be handle cases like __global int*
__local pG;<br>
(which means the pointer value itself resides in __local
memory, and the data it points to is in __global memory).<br>
</blockquote>
<div><br>
</div>
<div>ugh... that could be interesting... possible, though.
Are these always global (module-level) variables? (or can
they be function locals, parameters, etc?)</div>
</div>
</div>
</div>
</blockquote></span>
It depends, but they can be locals or parameters although some
combinations can never be used legally in OpenCL. <br></div></blockquote><div><br></div></span><div>Sorry, hard to keep track of everything in my head.<br><br>So you mentioned the possibility of this sort of thing:<br><br>__global int* __local pG;<br><br>a global variable in the __local address space which is itself a pointer to an integer in the __global address space.<br><br>You also mentioned the possibiilty of optimizations moving values between address spaces. Could they change the address space of the target of such a pointer (could they change the __global marker in the above to be something else?)<br><br>So long as they only change the top level address space, then this is probably practical, we can use the llvm::Value's address space for the top level address spaciness, then use DW_OP_xderef to describe that address space in the location expression.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Should passes mutating the physical address space of
values be responsible for updating the address space in
the debug info, </blockquote>
<div><br>
</div>
<div>This is one of the reasons why using the address space
of the llvm::Value itself would be useful - it wouldn't
have to be updated by optimization passes, it would just
be the single source of truth.</div>
</div>
</div>
</div>
</blockquote>
<br></span>
Is there something that already exists which does something similar?
All of the other debug info pieces I've looked at seem to emit
various kinds of constants<br></div></blockquote></span><div><br>Where are you looking/comparing for reference? </div></div><br></div></div>
</div><br></div>