<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Jingyue Wu" <jingyue@google.com><br><b>To: </b>"Matt Arsenault" <Matthew.Arsenault@amd.com><br><b>Cc: </b>llvm-dev@lists.llvm.org, "Hal Finkel" <hfinkel@anl.gov>, "Justin Holewinski" <jholewinski@nvidia.com>, "Eli Bendersky" <eliben@google.com>, "Xuetian Weng" <xweng@google.com><br><b>Sent: </b>Friday, August 7, 2015 3:44:29 PM<br><b>Subject: </b>Re: [RFC] BasicAA considers address spaces?<br><br><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 7, 2015 at 12:01 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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div><div class="h5">
<div>On 08/07/2015 11:35 AM, Jingyue Wu
wrote:<br>
</div>
<blockquote>
<div dir="ltr">+ the new llvm-dev</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Aug 7, 2015 at 11:30 AM,
Jingyue Wu <span dir="ltr"><<a href="mailto:jingyue@google.com" target="_blank">jingyue@google.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr">
<div>Hi folks,</div>
<div><br>
</div>
<div>Unsurprisingly, leveraging the fact that certain
address spaces don't alias can significantly improve
alias analysis precision and enhance (observably 2x
performance gain) load/store optimizations such as LICM
and DSE. </div>
<div><br>
</div>
<div>This sounds to me an overdue feature. I saw several
discussion threads on that direction, but none of them
really happened. </div>
<div><br>
</div>
(1) <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111010/129615.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111010/129615.html</a>.
Justin Holewinski proposed to add an address-space alias
analysis that treats pointers in different address spaces
not aliasing. This patch got shot down because, in some
targets, address spaces may alias. For example, in
CUDA+NVPTX, addrspace(0) aliases everyone.
<div>
<div><br>
</div>
<div>(2) <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064620.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064620.html</a>.
Michele Scandale proposed address space extensions in
IR metadata which TBAA could then leverage to prove
non-aliasing. This approach didn't fly either because
address spaces are target-specific. The front end
doesn't know enough to decide aliasing. <br>
</div>
<br>
So, can we make BasicAA to consider address spaces?
Specifically, I am proposing:</div>
<div>a) adding a new interface like
TTI::addressSpacesAlias(unsigned, unsigned), and</div>
<div>b) adding a little piece of logic in BasicAA that
reports "no alias" if address spaces don't alias. </div>
<div><br>
</div>
<div>This approach addresses the issue brought up in (2)
because TTI can see the entire codegen. It also resolves
the issue that shut down (1) because it allows address
spaces to alias in a target-defined way. Actually, John
Criswell did mention in that thread the idea of
embedding alias info in TargetData. Now that we have
TTI, it seems a better place to hold target-specific
alias info than DataLayout. </div>
<div><br>
</div>
<div>Any comments? </div>
<span><font color="#888888">
<div><br>
</div>
<div>Jingyue</div>
</font></span></div>
</blockquote>
</div>
<br>
</div>
</blockquote></div></div>
We definitely need something to handle this.<br>
<br>
I think a TTI::addressSpaceAlias is a good idea, although I don't
think this fully solves the language vs. target address space
distinction a metadata based approach was supposed to handle
although it would be easier to implement. For our GPU purposes this
would mostly be enough. For example, the fact that in OpenCL local
vs. global pointers won't alias is a useful distinction, even though
for a CPU target those will all be mapped to </div></blockquote><div><br></div><div id="DWT1487">Thanks for pointing this out, Matt. In that case, I'd suggest LLVM have both TTI- and metadata-based approaches, the former for targets being more knowledgeable, and the latter for front-ends being more knowledgeable. They are quite orthogonal.</div></div></div></div></blockquote><br>I don't understand this. If the frontend has more target knowledge than the target, something seems wrong. Could you please provide an example of when this could be a useful setup, and such knowledge should not be moved into the target?<br><br> -Hal<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>address space 0 so in
some cases the frontend knows more about aliasing address spaces
than the target.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Matt<br>
</font></span></div>
</blockquote></div><br></div></div>
</blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>