<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 24, 2015 at 1:25 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 text="#000000" bgcolor="#FFFFFF"><span class="">
<div>On 08/20/2015 04:55 PM, David Blaikie
via llvm-commits wrote:<br>
</div>
<blockquote type="cite">
<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" target="_blank">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" target="_blank">Matthew.Arsenault@amd.com</a>><br>
Cc: "Robinson, Paul" <<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>>,
"<a href="mailto:reviews%2BD11635%2Bpublic%2B0b7e77dd124b8ed5@reviews.llvm.org" target="_blank">reviews+D11635+public+0b7e77dd124b8ed5@reviews.llvm.org</a>"
<<a href="mailto:reviews%2BD11635%2Bpublic%2B0b7e77dd124b8ed5@reviews.llvm.org" target="_blank">reviews+D11635+public+0b7e77dd124b8ed5@reviews.llvm.org</a>>,
"<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a>"
<<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a>><br>
<br>
<br>
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>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>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote></span>
I don't think an optimization could reasonably change the address
space of something with pointers stored to memory like this, so I
don't think this is something that needs to be worried about.<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><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>
<div> </div>
</span></div>
</div>
</div>
</div>
</div>
</blockquote></span>
This is confusing me. This seems to be a separate and parallel
mechanism from DW_AT_address_class which describes how to load the
data. If the problem we were trying to solve was knowing what
address space to really load from was, then what is the purpose of
DW_AT_address_class again? Why are both necessary? If this is how
the access is described, it seems like DW_AT_address_class being
part of the source type would make more sense.<br></div></blockquote><div><br>I don't know much about address spaces, or DWARF's rendering of them, I'm just making some pretty rough guesses based on what I can figure out.<br><br>My main concern about encoding this is the type info is that it'll be hard for LLVM to update if optimizations change the address space of a variable (for the most part, type-related debug information is opaque to LLVM). Also, if an optimization can change the address space of a variable, then I imagine it could, in theory, split that - placing the variable in one address space for part of its lifetime and another address space for another part of the lifetime. If that's the case then it's no longer hard, but impossible, to use the type information to describe the address space - which is why I'd be inclined towards the DWARF expression version of address space encoding (if it's applicable, and I admit my domain ignorance here may have me barking up the wrong tree - though if it's not applicable I'm concerned that DWARF is insufficiently descriptive) rather than the type encoding of address spaces.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">The spec says "The size of the data retrieved from the dereferenced
address is the size of an address on the target machine.", but part
of the problem we're solving is that different address spaces have
different sizes. I guess this isn't really a problem, since it's an
implementation defined operation.<br></div></blockquote><div><br>Yeah, that might just be a bug in the spec that would need to be generalized to "the size of an address of the specified kind on the target machine", etc.<br><br>- Dave<br> </div></div><br></div></div>