<div dir="ltr">Then, we need to run this target-provided AA under -O3 to benefit the optimizations in O3. <div><br></div><div>I'm not sure what's the best practice of doing this. One way is pass</div><div>1) add a new interface TTI.getTargetAwareAliasAnalysis that returns the target-provided AA or nullptr</div><div>2) Embed TTI in PassManagerBuilder</div><div>3) When PassManagerBuilder::addInitialAliasAnalysisPass adds TTI.getTargetAwareAliasAnalysis to the pipeline. </div><div><br></div><div>Any better ideas? </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 12, 2015 at 12:24 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: "Hal Finkel via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
> To: "Daniel Berlin" <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>><br>
> Cc: <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>, "Justin Holewinski" <<a href="mailto:jholewinski@nvidia.com">jholewinski@nvidia.com</a>><br>
> Sent: Wednesday, August 12, 2015 2:06:41 PM<br>
> Subject: Re: [llvm-dev] [RFC] BasicAA considers address spaces?<br>
><br>
> ----- Original Message -----<br>
> > From: "Daniel Berlin" <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>><br>
> > To: "Jingyue Wu" <<a href="mailto:jingyue@google.com">jingyue@google.com</a>><br>
> > Cc: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>>, <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>,<br>
> > "Justin Holewinski" <<a href="mailto:jholewinski@nvidia.com">jholewinski@nvidia.com</a>><br>
> > Sent: Wednesday, August 12, 2015 2:03:34 PM<br>
> > Subject: Re: [llvm-dev] [RFC] BasicAA considers address spaces?<br>
> ><br>
> > SGTM<br>
><br>
> +1<br>
<br>
</span>Actually, upon further reflection, I don't we should create a new AA interface for this unless that's really necessary. AA passes can currently provide alias, pointsToConstantMemory, getArgModRefInfo, etc. and the target can quite reasonably want to enhance many of these.<br>
<br>
Unless there's some reason why we can't, I think we should provide the target the ability to provide an AA analysis pass to be inserted in the chain, or maybe TTI should just *be* an AA pass that gets inserted into the chain?<br>
<br>
 -Hal<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
>  -Hal<br>
><br>
> ><br>
> > On Wed, Aug 12, 2015 at 12:00 PM, Jingyue Wu via llvm-dev<br>
> > <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> > > I was lost from the thread at some point.<br>
> > ><br>
> > > Making the interface more general sounds good to me. This helps<br>
> > > to<br>
> > > solve<br>
> > > Escha's concern that targets can know more about aliasing than<br>
> > > just<br>
> > > comparing address spaces.<br>
> > ><br>
> > > If there are no objections, I'll<br>
> > > 1) add a new interface to TTI such as isTriviallyDisjoint. It<br>
> > > returns false<br>
> > > by default.<br>
> > > 2) create a new AA that checks this interface, and add it to the<br>
> > > AA<br>
> > > chain.<br>
> > > It could be named TargetAwareAliasAnalysis.<br>
> > ><br>
> > > Jingyue<br>
> > ><br>
> > > On Sun, Aug 9, 2015 at 2:34 PM, Hal Finkel via llvm-dev<br>
> > > <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> > >><br>
> > >> ----- 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>
> > >> > Cc: "Matt Arsenault" <<a href="mailto:Matthew.Arsenault@amd.com">Matthew.Arsenault@amd.com</a>>,<br>
> > >> > <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<br>
> > >> > spaces?<br>
> > >> ><br>
> > >> > Personally I feel the most intuitive approach would be to have<br>
> > >> > an<br>
> > >> > equivalent of isTriviallyDisjoint for IR; we already have a<br>
> > >> > model<br>
> > >> > for how it would work, and it could be a TTI call. I’ve kind<br>
> > >> > of<br>
> > >> > wanted this for a while because there’s a lot of<br>
> > >> > address-space-esque<br>
> > >> > aliasing relationships that can’t be easily modeled on the IR<br>
> > >> > level.<br>
> > >> ><br>
> > >> > For example (in our model), we have some constraints like<br>
> > >> > this:<br>
> > >> ><br>
> > >> > Global memory can’t alias local memory.<br>
> > >> > Global writeable memory can’t alias global readonly memory<br>
> > >> > (different<br>
> > >> > address spaces).<br>
> > >> > Stack memory can’t alias global memory (different address<br>
> > >> > spaces).<br>
> > >> > Texture reads cannot alias texture writes, because you can’t<br>
> > >> > bind a<br>
> > >> > texture as readable and writeable at the same time. Texture<br>
> > >> > writes,<br>
> > >> > however, can alias each other.<br>
> > >> > Vertex shader outputs can’t really alias each other, even<br>
> > >> > though<br>
> > >> > 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<br>
> > >> > disjoint<br>
> > >> > function in our backend is like 50 lines of code to cover all<br>
> > >> > the<br>
> > >> > cases), but a few of them are slightly more complex than<br>
> > >> > “address<br>
> > >> > space A can’t alias B”, so having a generic callback might be<br>
> > >> > nicer<br>
> > >> > and more powerful than a “does address space A alias address<br>
> > >> > space<br>
> > >> > B” callback, I think.<br>
> > >><br>
> > >> Could you provide a specific example of a case where the address<br>
> > >> space is<br>
> > >> not enough? [maybe you did above, but if so, I don't know which<br>
> > >> one].<br>
> > >><br>
> > >> Perhaps we should just do the most generic thing: Provide an<br>
> > >> AA/TTI shim<br>
> > >> which allows any target provide an implementation of AA (as part<br>
> > >> of the<br>
> > >> chain of AA passes). Thoughts?<br>
> > >><br>
> > >>  -Hal<br>
> > >><br>
> > >> ><br>
> > >> > —escha<br>
> > >><br>
> > >> --<br>
> > >> Hal Finkel<br>
> > >> Assistant Computational Scientist<br>
> > >> Leadership Computing Facility<br>
> > >> Argonne National Laboratory<br>
> > >> _______________________________________________<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>
> > ><br>
> > ><br>
> > ><br>
> > > _______________________________________________<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>
> > ><br>
> ><br>
><br>
> --<br>
> Hal Finkel<br>
> Assistant Computational Scientist<br>
> Leadership Computing Facility<br>
> Argonne National Laboratory<br>
> _______________________________________________<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>
><br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
_______________________________________________<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>