<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 7, 2015 at 12:22 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Aug 7, 2015 at 11:35 AM, Jingyue Wu via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> + the new llvm-dev<br>
><br>
> On Fri, Aug 7, 2015 at 11:30 AM, Jingyue Wu <<a href="mailto:jingyue@google.com">jingyue@google.com</a>> wrote:<br>
>><br>
>> Hi folks,<br>
>><br>
>> Unsurprisingly, leveraging the fact that certain address spaces don't<br>
>> alias can significantly improve alias analysis precision and enhance<br>
>> (observably 2x performance gain) load/store optimizations such as LICM and<br>
>> DSE.<br>
<br>
</span>Not shocking<br>
<span class=""><br>
>><br>
>> This sounds to me an overdue feature. I saw several discussion threads on<br>
>> that direction, but none of them really happened.<br>
>><br>
>> (1)<br>
>> <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111010/129615.html" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111010/129615.html</a>.<br>
>> Justin Holewinski proposed to add an address-space alias analysis that<br>
>> treats pointers in different address spaces not aliasing. This patch got<br>
>> shot down because, in some targets, address spaces may alias. For example,<br>
>> in CUDA+NVPTX, addrspace(0) aliases everyone.<br>
<br>
</span>ITYM other addrspace may alias addrspace(0).<br>
<br>
Sorry to be pedantic, but i think it's important to make sure we are<br>
all on the same page that backends can't change the aliasing behavior<br>
of the default address space, only the aliasing behavior of the other<br>
address spaces.<br>
<span class=""><br>
>><br>
>> So, can we make BasicAA to consider address spaces? Specifically, I am<br>
>> proposing:<br>
>> a) adding a new interface like TTI::addressSpacesAlias(unsigned,<br>
>> unsigned), and<br>
>> b) adding a little piece of logic in BasicAA that reports "no alias" if<br>
>> address spaces don't alias.<br>
<br>
<br>
>><br>
>> This approach addresses the issue brought up in (2) because TTI can see<br>
>> the entire codegen. It also resolves the issue that shut down (1) because it<br>
>> allows address spaces to alias in a target-defined way. Actually, John<br>
>> Criswell did mention in that thread the idea of embedding alias info in<br>
>> TargetData. Now that we have TTI, it seems a better place to hold<br>
>> target-specific alias info than DataLayout.<br>
>><br>
>> Any comments?<br>
<br>
</span>First, I agree this is a really useful feature to have.<br>
If it really is target specific (and it seems to be), ISTM like TTI is<br>
the right place to add a hook.<br>
<br>
However, i'd still rather see it as a pass (as it was in 2011) and<br>
something exposing the AA interface, than further push things into<br>
basicaa.<br>
<br>
It's not at all clear to me why basicaa should have this knowledge.</blockquote><div><br></div><div>Either way sounds fine with me. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But this is a mild preference, if others think this is a bad idea, ...<br>
</blockquote></div><br></div></div>