<div dir="ltr">Add the right llvm-commits.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 3:59 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Aug 5, 2015 at 6:36 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>On 08/03/2015 11:38 AM, David Blaikie wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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 <br>
</blockquote></span>
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? </blockquote><div><br></div></span><div>Good question.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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;<br>
(which means the pointer value itself resides in __local memory, and the data it points to is in __global memory).<br></blockquote><div><br></div></span><div>ugh... that could be interesting... possible, though. Are these always global (module-level) variables? (or can they be function locals, parameters, etc?)</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Should passes mutating the physical address space of values be responsible for updating the address space in the debug info, </blockquote><div><br></div></span><div>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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<span><font color="#888888"><br>
<br>
-Matt<br>
</font></span></blockquote></span></div><br></div></div>
</blockquote></div><br></div>