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

[David Blaikie via llvm-commits]

On Mon, Aug 24, 2015 at 1:25 PM, Matt Arsenault <Matthew.Arsenault at amd.com>
wrote:

> On 08/20/2015 04:55 PM, David Blaikie via llvm-commits wrote:
>
> (list switch)
> ---------- Forwarded message ----------
> From: David Blaikie <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>
> Cc: "Robinson, Paul" <Paul_Robinson at playstation.sony.com>, "
> reviews+D11635+public+0b7e77dd124b8ed5 at reviews.llvm.org" <
> reviews+D11635+public+0b7e77dd124b8ed5 at reviews.llvm.org>, "
> llvm-commits at cs.uiuc.edu" <llvm-commits at cs.uiuc.edu>
>
>
>
>
> On Mon, Aug 10, 2015 at 3:00 PM, Matt Arsenault <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
>> > 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.
>

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.

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.


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

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.

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