<div dir="ltr">Hi Michele,<div><br></div><div><div>Are you considering nested address spaces?<br></div></div><div><br></div><div>Apart from OpenCL, named address spaces have been proposed in scope of "Embedded C" draft N1275 (2007).</div>
<div><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf</a><br></div><div><br></div><div>--> Section 5.2: Named address spaces and named-register storage classes<br>
</div><div><br></div><div>Summarizing, address spaces may overlap in a nested fashion. Typically their names are intrinsic identifiers (e.g. "_x int t;" ) predefined at the start of translation unit,</div><div>but draft also mentions optional support for user-defined address spaces.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 8, 2013 at 12:52 AM, 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">Hello to everybody,<br>
<br>
I would like to start a discussion about a possible extension of address space concept in LLVM.<br>
<br>
The idea was born starting from this discussion in the clang mailing list (first msg: <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130715/084011.html" target="_blank">http://lists.cs.uiuc.edu/<u></u>pipermail/cfe-commits/Week-of-<u></u>Mon-20130715/084011.html</a> - interesting point: <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130722/084499.html" target="_blank">http://lists.cs.uiuc.edu/<u></u>pipermail/cfe-commits/Week-of-<u></u>Mon-20130722/084499.html</a>) where the fact that "source language level" informations about address spaces can be useful to perform optimizations in the middle end.<br>

<br>
IMHO this information should be a plus that could be *safely* ignored when not necessary and used where it can provide an improvement in optimizations. This does not necessary mean the the middle-end (and the back-ends) must be aware of the semantic of these logical address spaces, it would be enough just to distinguish between two logically different address spaces.<br>

The first application I see is alias analysis: for targets that do not have different physical address spaces (e.g. X86), meaning that in the IR the 'addrspace' modifier *should* not be present, the knowledge that two pointers refers to different logical address spaces (e.g. OpenCL address spaces) can be used to decide the aliasing.<br>

<br>
Currently the 'addrspace' modifier refers to target defined address spaces (physical address spaces), so I would like to know if this extension is a reasonable approach.<br>
Otherwise changing the 'addrspace' semantic could allow an alternative way: the middle end would be "automatically" aware of this information but the address space lowering must be moved elsewhere before the instruction selection using some language-specific pass the produce the correct lowering. An issue with this approach is that the middle-end/back-end pipeline it will rely on a language specific pass or equivalent mechanism during the instruction selection.<br>

<br>
Thanks in advance for the attention and for your future answer.<br>
<br>
Best regards,<br>
<br>
Michele Scandale<br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<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><br>
</blockquote></div><br></div>