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

[David Blaikie via llvm-commits]

(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?)

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.


>
>
>
>
>>
>> Should passes mutating the physical address space of values be
>> responsible for updating the address space in the debug info,
>
>
> 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.
>
>
> 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
>

Where are you looking/comparing for reference?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150820/62bbf1ae/attachment.html>