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

[Matt Arsenault]

On 07/30/2015 01:59 PM, David Blaikie wrote:
>
>
> On Thu, Jul 30, 2015 at 1:41 PM, Matt Arsenault 
> <Matthew.Arsenault at amd.com <mailto:Matthew.Arsenault at amd.com>> wrote:
>
>     On 07/30/2015 10:54 AM, David Blaikie wrote:
>
>         If we could rely on the llvm::Value that the debug info
>         variable description points to always having a PointerType
>         with the desired address space, then we could just get it from
>         there & wouldn't need to add more info to the debug info
>         variable description.
>
>     OK, I see what you mean now. We would like to be able to change
>     the address space of the value for optimization purposes, but
>     still report the source address space. For example, the
>     AMDGPUPromoteAlloca pass now currently tries to replace allocas in
>     address space 0 with globals in address space 3.
>
>
> Interesting - what's the debugger going to do with the address space, 
> though? Is it going to need to know the real address space, or the 
> original one?
>
I would expect the debugger to show the original address space. If it 
needed to know the address space of the actual load / store, it could 
look at what machine instruction is being executed.

I'm trying to add addrSpace as a first class member of DIDerivedType 
like SizeInBits/AlignInBits, but this seems to require touching more 
components than I expected. Does this field really need to be added to 
MDNodeKeyImpl? This seems like a lower level place than I expected 
needing to touch. I would expect people would want to avoid adding new 
fields to things like this to save memory

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150730/9a7114ce/attachment.html>