[llvm-dev] [RFC] BasicAA considers address spaces?

Wed Aug 12 13:39:52 PDT 2015

Then, we need to run this target-provided AA under -O3 to benefit the
optimizations in O3.

I'm not sure what's the best practice of doing this. One way is pass
1) add a new interface TTI.getTargetAwareAliasAnalysis that returns the
target-provided AA or nullptr
2) Embed TTI in PassManagerBuilder
3) When PassManagerBuilder::addInitialAliasAnalysisPass adds
TTI.getTargetAwareAliasAnalysis to the pipeline.

Any better ideas?

On Wed, Aug 12, 2015 at 12:24 PM, Hal Finkel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> ----- Original Message -----
> > From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org>
> > To: "Daniel Berlin" <dberlin at dberlin.org>
> > Cc: llvm-dev at lists.llvm.org, "Justin Holewinski" <jholewinski at nvidia.com
> >
> > Sent: Wednesday, August 12, 2015 2:06:41 PM
> > Subject: Re: [llvm-dev] [RFC] BasicAA considers address spaces?
> >
> > ----- Original Message -----
> > > From: "Daniel Berlin" <dberlin at dberlin.org>
> > > To: "Jingyue Wu" <jingyue at google.com>
> > > Cc: "Hal Finkel" <hfinkel at anl.gov>, llvm-dev at lists.llvm.org,
> > > "Justin Holewinski" <jholewinski at nvidia.com>
> > > Sent: Wednesday, August 12, 2015 2:03:34 PM
> > > Subject: Re: [llvm-dev] [RFC] BasicAA considers address spaces?
> > >
> > > SGTM
> >
> > +1
>
> 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.
>
> 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?
>
>  -Hal
>
> >
> >  -Hal
> >
> > >
> > > On Wed, Aug 12, 2015 at 12:00 PM, Jingyue Wu via llvm-dev
> > > <llvm-dev at lists.llvm.org> wrote:
> > > > I was lost from the thread at some point.
> > > >
> > > > 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.
> > > >
> > > > If there are no objections, I'll
> > > > 1) add a new interface to TTI such as isTriviallyDisjoint. It
> > > > returns false
> > > > by default.
> > > > 2) create a new AA that checks this interface, and add it to the
> > > > AA
> > > > chain.
> > > > It could be named TargetAwareAliasAnalysis.
> > > >
> > > > Jingyue
> > > >
> > > > On Sun, Aug 9, 2015 at 2:34 PM, Hal Finkel via llvm-dev
> > > > <llvm-dev at lists.llvm.org> wrote:
> > > >>
> > > >> ----- Original Message -----
> > > >> > From: "escha" <escha at apple.com>
> > > >> > To: "Hal Finkel" <hfinkel at anl.gov>
> > > >> > Cc: "Matt Arsenault" <Matthew.Arsenault at amd.com>,
> > > >> > llvm-dev at lists.llvm.org, "Justin Holewinski"
> > > >> > <jholewinski at nvidia.com>
> > > >> > Sent: Sunday, August 9, 2015 7:46:26 AM
> > > >> > Subject: Re: [llvm-dev] [RFC] BasicAA considers address
> > > >> > spaces?
> > > >> >
> > > >> > Personally I feel the most intuitive approach would be to have
> > > >> > an
> > > >> > equivalent of isTriviallyDisjoint for IR; we already have a
> > > >> > model
> > > >> > for how it would work, and it could be a TTI call. I’ve kind
> > > >> > of
> > > >> > wanted this for a while because there’s a lot of
> > > >> > address-space-esque
> > > >> > aliasing relationships that can’t be easily modeled on the IR
> > > >> > level.
> > > >> >
> > > >> > For example (in our model), we have some constraints like
> > > >> > this:
> > > >> >
> > > >> > Global memory can’t alias local memory.
> > > >> > Global writeable memory can’t alias global readonly memory
> > > >> > (different
> > > >> > address spaces).
> > > >> > Stack memory can’t alias global memory (different address
> > > >> > spaces).
> > > >> > Texture reads cannot alias texture writes, because you can’t
> > > >> > bind a
> > > >> > texture as readable and writeable at the same time. Texture
> > > >> > writes,
> > > >> > however, can alias each other.
> > > >> > Vertex shader outputs can’t really alias each other, even
> > > >> > though
> > > >> > they
> > > >> > are technically “stores”.
> > > >> > (there’s more where that came from)
> > > >> >
> > > >> > These are all very trivial to express in code (the trivially
> > > >> > disjoint
> > > >> > function in our backend is like 50 lines of code to cover all
> > > >> > the
> > > >> > cases), but a few of them are slightly more complex than
> > > >> > “address
> > > >> > space A can’t alias B”, so having a generic callback might be
> > > >> > nicer
> > > >> > and more powerful than a “does address space A alias address
> > > >> > space
> > > >> > B” callback, I think.
> > > >>
> > > >> 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].
> > > >>
> > > >> 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?
> > > >>
> > > >>  -Hal
> > > >>
> > > >> >
> > > >> > —escha
> > > >>
> > > >> --
> > > >> Hal Finkel
> > > >> Assistant Computational Scientist
> > > >> Leadership Computing Facility
> > > >> Argonne National Laboratory
> > > >> _______________________________________________
> > > >> LLVM Developers mailing list
> > > >> llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
> > > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > LLVM Developers mailing list
> > > > llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
> > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > > >
> > >
> >
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org         http://llvm.cs.uiuc.edu
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150812/907ede74/attachment-0001.html>