Fwd: [PATCH] D11635: DebugInfo: Emit DW_AT_address_class for non-0 address space

[Matt Arsenault via llvm-commits]

On 08/20/2015 04:55 PM, David Blaikie via llvm-commits wrote:
> (list switch)
> ---------- Forwarded message ----------
> From: *David Blaikie* <dblaikie at gmail.com <mailto:dblaikie at gmail.com>>
> Date: Thu, Aug 20, 2015 at 4:52 PM
> Subject: Re: [PATCH] D11635: DebugInfo: Emit DW_AT_address_class for 
> non-0 address space
> To: Matt Arsenault <Matthew.Arsenault at amd.com 
> <mailto:Matthew.Arsenault at amd.com>>
> Cc: "Robinson, Paul" <Paul_Robinson at playstation.sony.com 
> <mailto:Paul_Robinson at playstation.sony.com>>, 
> "reviews+D11635+public+0b7e77dd124b8ed5 at reviews.llvm.org 
> <mailto:reviews%2BD11635%2Bpublic%2B0b7e77dd124b8ed5 at reviews.llvm.org>" <reviews+D11635+public+0b7e77dd124b8ed5 at reviews.llvm.org 
> <mailto:reviews%2BD11635%2Bpublic%2B0b7e77dd124b8ed5 at reviews.llvm.org>>, 
> "llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>" 
> <llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>>
>
>
>
>
> On Mon, Aug 10, 2015 at 3:00 PM, Matt Arsenault 
> <Matthew.Arsenault at amd.com <mailto:Matthew.Arsenault at amd.com>> wrote:
>
>     On 08/06/2015 03:59 PM, David Blaikie wrote:
>>
>>
>>     On Wed, Aug 5, 2015 at 6:36 PM, Matt Arsenault
>>     <Matthew.Arsenault at amd.com <mailto:Matthew.Arsenault at amd.com>> wrote:
>>
>>         On 08/03/2015 11:38 AM, David Blaikie wrote:
>>
>>
>>             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
>>
>>         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? 
>>
>>
>>     Good question.
>>
>>         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;
>>         (which means the pointer value itself resides in __local
>>         memory, and the data it points to is in __global memory).
>>
>>
>>     ugh... that could be interesting... possible, though. Are these
>>     always global (module-level) variables? (or can they be function
>>     locals, parameters, etc?)
>     It depends, but they can be locals or parameters although some
>     combinations can never be used legally in OpenCL.
>
>
> Sorry, hard to keep track of everything in my head.
>
> So you mentioned the possibility of this sort of thing:
>
> __global int* __local pG;
>
> a global variable in the __local address space which is itself a 
> pointer to an integer in the __global address space.
>
> 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?)
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.


>
> 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.
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.

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150824/3bb9688e/attachment.html>