<div dir="ltr">I was lost from the thread at some point. <div><br></div><div>Making the interface more general sounds good to me. This helps to solve Escha's concern that targets can know more about aliasing than just comparing address spaces. </div><div><br></div><div>If there are no objections, I'll </div><div>1) add a new interface to TTI such as isTriviallyDisjoint. It returns false by default. </div><div>2) create a new AA that checks this interface, and add it to the AA chain. It could be named TargetAwareAliasAnalysis. </div><div><br></div><div>Jingyue</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 9, 2015 at 2:34 PM, Hal Finkel via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.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="">----- Original Message -----<br>
> From: "escha" <<a href="mailto:escha@apple.com">escha@apple.com</a>><br>
> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
</span><div><div class="h5">> Cc: "Matt Arsenault" <<a href="mailto:Matthew.Arsenault@amd.com">Matthew.Arsenault@amd.com</a>>, <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>, "Justin Holewinski"<br>
> <<a href="mailto:jholewinski@nvidia.com">jholewinski@nvidia.com</a>><br>
> Sent: Sunday, August 9, 2015 7:46:26 AM<br>
> Subject: Re: [llvm-dev] [RFC] BasicAA considers address spaces?<br>
><br>
> Personally I feel the most intuitive approach would be to have an<br>
> equivalent of isTriviallyDisjoint for IR; we already have a model<br>
> for how it would work, and it could be a TTI call. I’ve kind of<br>
> wanted this for a while because there’s a lot of address-space-esque<br>
> aliasing relationships that can’t be easily modeled on the IR level.<br>
><br>
> For example (in our model), we have some constraints like this:<br>
><br>
> Global memory can’t alias local memory.<br>
> Global writeable memory can’t alias global readonly memory (different<br>
> address spaces).<br>
> Stack memory can’t alias global memory (different address spaces).<br>
> Texture reads cannot alias texture writes, because you can’t bind a<br>
> texture as readable and writeable at the same time. Texture writes,<br>
> however, can alias each other.<br>
> Vertex shader outputs can’t really alias each other, even though they<br>
> are technically “stores”.<br>
> (there’s more where that came from)<br>
><br>
> These are all very trivial to express in code (the trivially disjoint<br>
> function in our backend is like 50 lines of code to cover all the<br>
> cases), but a few of them are slightly more complex than “address<br>
> space A can’t alias B”, so having a generic callback might be nicer<br>
> and more powerful than a “does address space A alias address space<br>
> B” callback, I think.<br>
<br>
</div></div>Could you provide a specific example of a case where the address space is not enough? [maybe you did above, but if so, I don't know which one].<br>
<br>
Perhaps we should just do the most generic thing: Provide an AA/TTI shim which allows any target provide an implementation of AA (as part of the chain of AA passes). Thoughts?<br>
<br>
 -Hal<br>
<br>
><br>
> —escha<br>
<span class="im HOEnZb"><br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>