Hal Finkel via llvm-dev
2015-Aug-12 19:06 UTC
[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 -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
Hal Finkel via llvm-dev
2015-Aug-12 19:24 UTC
[llvm-dev] [RFC] BasicAA considers address spaces?
----- 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 > > +1Actually, 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
Jingyue Wu via llvm-dev
2015-Aug-12 20:39 UTC
[llvm-dev] [RFC] BasicAA considers address spaces?
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>
Daniel Berlin via llvm-dev
2015-Aug-12 21:36 UTC
[llvm-dev] [RFC] BasicAA considers address spaces?
So, the one downside of doing it this way is that the information never will get to the other parts of the world. We definitely don't want to go crazy and have tons of target-specific alias info encoded into the AA interface. I agree also, in general, this belongs in an AA pass and not the interface (IE i don't think basicaa needs it). However, for things like "memory spaces being disjoint", some other AA passes may want to be able to know that. IE If CFL-AA can tell that memory spaces are disjoint, it could avoid unioning in stuff that can't really alias. Without such a hook, it would be relegated to calling something like alias() on every pair :P So i'm torn on how best to make that happen, without people going off and completely making things like basicaa super target-specific using hooks (such that it ends up providing pretty crappy answers unless you implement 60 different target hooks) On Wed, Aug 12, 2015 at 12:24 PM, Hal Finkel <hfinkel at anl.gov> 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