<div dir="ltr">On Wed, Aug 7, 2013 at 5:34 PM, Pete Cooper <span dir="ltr"><<a href="mailto:peter_cooper@apple.com" target="_blank">peter_cooper@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="h5"><div>On Aug 7, 2013, at 2:07 PM, Matt Arsenault <<a href="mailto:Matthew.Arsenault@amd.com" target="_blank">Matthew.Arsenault@amd.com</a>> wrote:</div>
<br><blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<div>On 08/07/2013 01:52 PM, Michele
Scandale wrote:<br>
</div>
<blockquote type="cite"><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>
<br>
</blockquote>
There was this patch from a long time ago that never went in to use
the address spaces for alias analysis:<br>
<a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111010/129728.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111010/129728.html</a><br>
<br>
The decision seems to be that LLVM addrspaces aren't required to not
alias. I was thinking of following the suggestion to make the
datalayout contain which address spaces can / cannot alias.
Alternatively, the tbaa metadata might be appropriate for this, but
I haven't looked at how that works.<br></div></blockquote></div></div>I haven’t thought about using TBAA metadata, but I think some form of metadata would be useful here.</div><div><br></div><div>In the clang discussion (<a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130715/084083.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130715/084083.html</a>) you noted that address space 3 could be considered constant. This is a very useful piece of information in itself, and is something we should have in the metadata. </div>
<div><br></div><div>I don’t know if CUDA has aliasing address spaces, but that would also be useful to consider. Something simple like this might work. Note i’m using the examples from the clang discussion, that is "1 = opencl/cuda global, 2 = opencl_local/cuda_shared, 3 = opencl/cuda constant"</div>
<div><br></div></div></blockquote><div><br></div><div>Yes, CUDA does have aliasing address spaces, but that is captured in your tree below. The generic address space (0) can represent addresses in the shared and global (local and global in OpenCL terms) address spaces.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div><br></div><div>!address_spaces = !{!0, !1, !2, !3}</div><div>
<br></div><div>; Address space tuple. { address space number, parent address space, additional properties }</div><div>!0 = metadata !{ i32 0, !{}, !{} }</div><div>!1 = metadata !{ i32 1, !0, !{} }<br>!2 = metadata !{ i32 2, !0, !{} }<br>
!3 = metadata !{ i32 3, !0, !4 }</div><div><br></div><div>!4 = metadata !{ “constant” }</div><div><br></div><div><br></div><div>This corresponds to 3 address spaces which all are members of address space 0, but which otherwise do not alias each other. I think this is roughly how TBAA does things. You can introduce any nodes in the tree of address spaces you need to make children in the tree alias each other.</div>
<div><br></div><div>Additionally, the last address space is marked as constant which could be used for optimization, e.g. LICM.</div><div><br></div><div>The alternative to this is to put everything in LLVM code itself. Personally I think metadata is better, but were it hard coded in the LLVM code i wouldn’t argue against it.</div>
</div></blockquote><div><br></div><div>Perhaps I'm just missing the context of the cfe-dev thread, but are these representing the target-dependent address spaces in the IR, or a language-specific address space mapping that is used to annotate the IR?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Thanks,</div><div>Pete<div class="im"><br><blockquote type="cite" dir="auto">
<div bgcolor="#FFFFFF" text="#000000">
</div>_______________________________________________<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/mailman/listinfo/llvmdev</a><br></blockquote></div></div><br></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">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/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</div></div>