<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 7, 2013 at 7:45 PM, Michele Scandale <span dir="ltr"><<a href="mailto:michele.scandale@gmail.com" target="_blank">michele.scandale@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 class="im">On 08/08/2013 01:36 AM, Justin Holewinski wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It's not clear to me how this would work for targets that use the same<br>
physical address space for multiple language-specific address spaces.<br>
If a target maps both constant and global to address space 42 (for<br>
example), how would the optimizer differentiate between these two?<br>
<br>
</blockquote>
<br></div>
I think that the proposal of Pete would imply that in the IR the logical address spaces are represented with addrspace modifier (3 for constant and 1 for global) so the optimizer can distinguish the two and using "address space metadata" can derive properties related to this address spaces.<br>
During the instruction selection the mapping information are used to drive the selection phase.<br>
<br>
IMO whenever possible both address spaces informations must be maintained.<br></blockquote><div><br></div><div>This worries me a bit. This would introduce language-specific processing into SelectionDAG. OpenCL maps address spaces one way, other languages map them in other ways. Currently, it is the job of the front-end to map pointers into the correct address space for the target (hence the address space map in clang). With (my understanding of) this proposal, there would be a pre-defined set of language-specific address spaces that the target would need to know about. IMO it should be the job of the front-end to do this mapping.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
On Wed, Aug 7, 2013 at 7:15 PM, Michele Scandale<br></div><div class="im">
<<a href="mailto:michele.scandale@gmail.com" target="_blank">michele.scandale@gmail.com</a> <mailto:<a href="mailto:michele.scandale@gmail.com" target="_blank">michele.scandale@<u></u>gmail.com</a>>> wrote:<br>
<br>
On 08/08/2013 12:55 AM, Matt Arsenault wrote:<br>
<br>
On 08/07/2013 03:52 PM, Michele Scandale wrote:<br>
<br>
<br>
In the opencl specification is said that the four address<br>
spaces are<br>
disjoint, so my conclusion of non aliasing with the others.<br>
<br>
In OpenCL 2.0, you can cast between the generic address space and<br>
global/local/private, so there's also that to consider.<br>
<br>
Thanks for correction. My reference was the opencl 1.2 specification.<br>
<br>
Considering the case of OpenCL 2.0 IMO we would have another address<br>
space that contains the private, the global and the local address<br>
spaces.<br>
<br>
<br>
-Michele<br>
<br></div>
______________________________<u></u>___________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <mailto:<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/__<u></u>mailman/listinfo/llvmdev</a><div class="im"><br>
<<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a>><br>
<br>
<br>
<br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Justin Holewinski<br>
</div></blockquote>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</div></div>