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

[David Blaikie via llvm-commits]

Add the right llvm-commits.

On Thu, Aug 6, 2015 at 3:59 PM, David Blaikie <dblaikie at gmail.com> 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?)
>
>
>>
>> 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.
>
>
>> or is there some other way values are supposed to be linked to their
>> types for this purpose? For our usecase I think having the pass strip debug
>> info is acceptable.
>>
>> -Matt
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150806/c7dbbad1/attachment.html>