<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 23, 2013, at 2:03 PM, Michele Scandale <<a href="mailto:michele.scandale@gmail.com">michele.scandale@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><blockquote type="cite"><br>Ok, this approach will work for me. However, I would prefer to not have CL prefix and keep it as AS#.<br><br></blockquote><br>This means that you want to revert the commit, removing the usage of the target-address space map, right?<br></blockquote><div><br></div><div>No. I wanted the specialized mangling that you are proposing in your patch but don't use "CL" as the prefix. Use "AS" for CL.</div><div><br></div><div>However, I actually should have looked at this closer as it actually doesn't map to what I want it to. I want it to be the following:</div><div><br></div><div><div style="margin: 0px; font-size: 11px; font-family: Menlo; color: rgb(0, 132, 0); "><span style="color: #272ad8">1</span><span style="color: #000000">, </span>// opencl_global</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; color: rgb(0, 132, 0); "><span style="color: #272ad8">3</span><span style="color: #000000">, </span>// opencl_local</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; color: rgb(0, 132, 0); "><span style="color: #272ad8">2</span><span style="color: #000000">, </span>// opencl_constant</div></div><div><br></div><div>and when there is no address space then it maps to nothing.</div><div><br></div><div>So, I don't think your patch is going to work unless the order is changed in the enum. Because this is not clearly defined in the spec and is implementation specific and TARGET specific.. then changing that enum is probably not going to be the right approach either.</div><div><br></div><div>So, I'm going back to my original statement to keep it to be Target specific. For your library, are these functions actually implemented differently? Wouldn't they be exactly the same when there is no address space? In our implementation we have an address space map defined for X86 and then the names get mangled "correctly" for all targets. But, all the functionality is the same since the address spaces don't impact codegen for X86.</div><div><br></div><div>-Tanya</div><br><blockquote type="cite"><br>If so it's still fine :-)<br><br>Thanks again.<br><br>-Michele<br></blockquote></div><br></body></html>