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

[Robinson, Paul]

The debug info generally should be mapping the source to the code/data as actually generated, even after optimizations shuffle things around. If the original code thinks it's allocating something in AS 0 but optimization puts it in AS 3, and the user asks the debugger to display the value, how does the debugger know to look in AS 3?  Asking the debugger to troll around looking for an instruction that it might guess is loading/storing the value and assuming that address is the actual location… seems like asking a bit much.
--paulr

From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Matt Arsenault
Sent: Thursday, July 30, 2015 5:39 PM
To: David Blaikie
Cc: reviews+D11635+public+0b7e77dd124b8ed5 at reviews.llvm.org; llvm-commits at cs.uiuc.edu
Subject: Re: [PATCH] D11635: DebugInfo: Emit DW_AT_address_class for non-0 address space

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/20150731/3884cd6d/attachment.html>