<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 30, 2015 at 1:41 PM, Matt Arsenault <span dir="ltr"><<a href="mailto:Matthew.Arsenault@amd.com" target="_blank">Matthew.Arsenault@amd.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 07/30/2015 10:54 AM, David Blaikie wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote></span>
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.<br></blockquote><div><br></div><div>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?</div><div> </div></div><br></div></div>