On 11/17/2017 02:01 AM, Hongbin Zheng wrote:> Do you mean a and b are noalias if: > > static int foo(int *a, int *b) { > return a[0] + b[0]; > } > > int bar(int *x) { > return foo(x+1, x); > } > > ? > > To me, because "AA.alias((x+1, MemoryLocation::UnknownSize), > (x, MemoryLocation::UnknownSize)) != NoAlias", so a and b are not noalias.Remember that MemoryLocation::UnknownSize is unknown, but positive. So you need to check both "AA.alias((x+1, MemoryLocation::UnknownSize), (x, MemoryLocation::UnknownSize)) == NoAlias" and "AA.alias((x, MemoryLocation::UnknownSize), (x+1, MemoryLocation::UnknownSize)) == NoAlias" to partition by underlying object. One of these should be false. -Hal> Maybe my version is too conservative. > > Thanks > Hongbin > > > On Thu, Nov 16, 2017 at 11:55 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > > On 11/17/2017 01:49 AM, Hongbin Zheng wrote: >> Could you elaborate "Note that, without further analysis of the >> uses of the potentially-noalias pointers, you can do this only ..."? >> Why the uses, instead of the def, of pointer matter? > > Both matter. > > static int foo(int *a, int *b) { > return a[0] + b[1]; > } > > int bar(int *x) { > return foo(x+1, x); > } > > You can't mark a and b as noalias here, even though NoAlias(x+1, > x) == true. This is why I was saying that, unless the pointers > come from distinct, identified underlying objects, you need to > look at the uses of the pointers too. > > -Hal > > P.S. As discussed in D4609, we probably want to try adding CGSCC > AA wrappers, to look back through function arguments, instead of > using attribute propagation. > > >> >> Thanks >> Hongbin >> >> On Thu, Nov 16, 2017 at 11:21 PM, Hal Finkel via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, Alexandre, >> >> We don't have anything currently which does this. Note that, >> without further analysis of the uses of the >> potentially-noalias pointers, you can do this only for >> arguments with distinct (and identified) underlying objects >> (i.e., you need something a bit stronger than just >> "non-aliasing pointers"). >> >> -Hal >> >> >> On 11/16/2017 10:11 AM, via llvm-dev wrote: >> >> Is this what you are looking for? >> >> https://reviews.llvm.org/D4609 >> >> Best, >> >> Haicheng Wu >> >> On 2017-11-14 20:34, Alexandre Isoard via llvm-dev wrote: >> >> Hello, >> >> Do we have a pass that propagate the noalias >> annotation down to the >> callee when: >> - it is static >> - it is always called with non aliasing pointers >> ? >> >> Or maybe that is incorrect? >> >> -- >> >> ALEXANDRE ISOARD >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >> >> >> -- >> Hal Finkel >> Lead, Compiler Technology and Programming Languages >> Leadership Computing Facility >> Argonne National Laboratory >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >> >> > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > >-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171117/1c95a6a1/attachment.html>
Hongbin Zheng via llvm-dev
2017-Nov-17 08:13 UTC
[llvm-dev] Propagating noalias annotation
On Fri, Nov 17, 2017 at 12:07 AM, Hal Finkel <hfinkel at anl.gov> wrote:> > On 11/17/2017 02:01 AM, Hongbin Zheng wrote: > > Do you mean a and b are noalias if: > > static int foo(int *a, int *b) { > return a[0] + b[0]; > } > > int bar(int *x) { > return foo(x+1, x); > } > > ? > > To me, because "AA.alias((x+1, MemoryLocation::UnknownSize), > (x, MemoryLocation::UnknownSize)) != NoAlias", so a and b are not noalias. > > > Remember that MemoryLocation::UnknownSize is unknown, but positive. So you > need to check both "AA.alias((x+1, MemoryLocation::UnknownSize), (x, > MemoryLocation::UnknownSize)) == NoAlias" and "AA.alias((x, > MemoryLocation::UnknownSize), (x+1, MemoryLocation::UnknownSize)) => NoAlias" to partition by underlying object. One of these should be false. >Thanks a lot for the explanation. Do you mean AA.alias(X,Y) may not always return the same result as AA.alias(Y,X)? (otherwise why we need to do both of them) [1] Didn't mention this detail. Thanks again Hongbin [1] https://llvm.org/docs/AliasAnalysis.html#the-alias-method> > > -Hal > > > Maybe my version is too conservative. > > Thanks > Hongbin > > > On Thu, Nov 16, 2017 at 11:55 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> >> On 11/17/2017 01:49 AM, Hongbin Zheng wrote: >> >> Could you elaborate "Note that, without further analysis of the uses of >> the potentially-noalias pointers, you can do this only ..."? >> Why the uses, instead of the def, of pointer matter? >> >> >> Both matter. >> >> static int foo(int *a, int *b) { >> return a[0] + b[1]; >> } >> >> int bar(int *x) { >> return foo(x+1, x); >> } >> >> You can't mark a and b as noalias here, even though NoAlias(x+1, x) =>> true. This is why I was saying that, unless the pointers come from >> distinct, identified underlying objects, you need to look at the uses of >> the pointers too. >> >> -Hal >> >> P.S. As discussed in D4609, we probably want to try adding CGSCC AA >> wrappers, to look back through function arguments, instead of using >> attribute propagation. >> >> >> >> Thanks >> Hongbin >> >> On Thu, Nov 16, 2017 at 11:21 PM, Hal Finkel via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi, Alexandre, >>> >>> We don't have anything currently which does this. Note that, without >>> further analysis of the uses of the potentially-noalias pointers, you can >>> do this only for arguments with distinct (and identified) underlying >>> objects (i.e., you need something a bit stronger than just "non-aliasing >>> pointers"). >>> >>> -Hal >>> >>> >>> On 11/16/2017 10:11 AM, via llvm-dev wrote: >>> >>>> Is this what you are looking for? >>>> >>>> https://reviews.llvm.org/D4609 >>>> >>>> Best, >>>> >>>> Haicheng Wu >>>> >>>> On 2017-11-14 20:34, Alexandre Isoard via llvm-dev wrote: >>>> >>>>> Hello, >>>>> >>>>> Do we have a pass that propagate the noalias annotation down to the >>>>> callee when: >>>>> - it is static >>>>> - it is always called with non aliasing pointers >>>>> ? >>>>> >>>>> Or maybe that is incorrect? >>>>> >>>>> -- >>>>> >>>>> ALEXANDRE ISOARD >>>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> >>> -- >>> Hal Finkel >>> Lead, Compiler Technology and Programming Languages >>> Leadership Computing Facility >>> Argonne National Laboratory >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> >> >> -- >> Hal Finkel >> Lead, Compiler Technology and Programming Languages >> Leadership Computing Facility >> Argonne National Laboratory >> >> > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171117/252ba4e2/attachment.html>
On 11/17/2017 02:13 AM, Hongbin Zheng wrote:> > > On Fri, Nov 17, 2017 at 12:07 AM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > > On 11/17/2017 02:01 AM, Hongbin Zheng wrote: >> Do you mean a and b are noalias if: >> >> static int foo(int *a, int *b) { >> return a[0] + b[0]; >> } >> >> int bar(int *x) { >> return foo(x+1, x); >> } >> >> ? >> >> To me, because "AA.alias((x+1, MemoryLocation::UnknownSize), >> (x, MemoryLocation::UnknownSize)) != NoAlias", so a and b are not >> noalias. > > Remember that MemoryLocation::UnknownSize is unknown, but > positive. So you need to check both "AA.alias((x+1, > MemoryLocation::UnknownSize), (x, MemoryLocation::UnknownSize)) => NoAlias" and "AA.alias((x, MemoryLocation::UnknownSize), (x+1, > MemoryLocation::UnknownSize)) == NoAlias" to partition by > underlying object. One of these should be false. > > > Thanks a lot for the explanation. > Do you mean AA.alias(X,Y) may not always return the same result as > AA.alias(Y,X)? (otherwise why we need to do both of them)Yes, but I should clarify (what I typed gives the wrong implication). If both values have an unknown size, then it should be symmetric. If only one is, however, there can be a difference between: | x | | y .... -> | and: | x ... -> | | y | and this is because the unknown size is unknown, but positive. -Hal> [1] Didn't mention this detail. > > Thanks again > Hongbin > > > [1] https://llvm.org/docs/AliasAnalysis.html#the-alias-method > > > > > -Hal > > >> Maybe my version is too conservative. >> >> Thanks >> Hongbin >> >> >> On Thu, Nov 16, 2017 at 11:55 PM, Hal Finkel <hfinkel at anl.gov >> <mailto:hfinkel at anl.gov>> wrote: >> >> >> On 11/17/2017 01:49 AM, Hongbin Zheng wrote: >>> Could you elaborate "Note that, without further analysis of >>> the uses of the potentially-noalias pointers, you can do >>> this only ..."? >>> Why the uses, instead of the def, of pointer matter? >> >> Both matter. >> >> static int foo(int *a, int *b) { >> return a[0] + b[1]; >> } >> >> int bar(int *x) { >> return foo(x+1, x); >> } >> >> You can't mark a and b as noalias here, even though >> NoAlias(x+1, x) == true. This is why I was saying that, >> unless the pointers come from distinct, identified underlying >> objects, you need to look at the uses of the pointers too. >> >> -Hal >> >> P.S. As discussed in D4609, we probably want to try adding >> CGSCC AA wrappers, to look back through function arguments, >> instead of using attribute propagation. >> >> >>> >>> Thanks >>> Hongbin >>> >>> On Thu, Nov 16, 2017 at 11:21 PM, Hal Finkel via llvm-dev >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> >>> wrote: >>> >>> Hi, Alexandre, >>> >>> We don't have anything currently which does this. Note >>> that, without further analysis of the uses of the >>> potentially-noalias pointers, you can do this only for >>> arguments with distinct (and identified) underlying >>> objects (i.e., you need something a bit stronger than >>> just "non-aliasing pointers"). >>> >>> -Hal >>> >>> >>> On 11/16/2017 10:11 AM, via llvm-dev wrote: >>> >>> Is this what you are looking for? >>> >>> https://reviews.llvm.org/D4609 >>> >>> Best, >>> >>> Haicheng Wu >>> >>> On 2017-11-14 20:34, Alexandre Isoard via llvm-dev >>> wrote: >>> >>> Hello, >>> >>> Do we have a pass that propagate the noalias >>> annotation down to the >>> callee when: >>> - it is static >>> - it is always called with non aliasing pointers >>> ? >>> >>> Or maybe that is incorrect? >>> >>> -- >>> >>> ALEXANDRE ISOARD >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >>> >>> >>> -- >>> Hal Finkel >>> Lead, Compiler Technology and Programming Languages >>> Leadership Computing Facility >>> Argonne National Laboratory >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >>> >>> >> >> -- >> Hal Finkel >> Lead, Compiler Technology and Programming Languages >> Leadership Computing Facility >> Argonne National Laboratory >> >> > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > >-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171117/e73082f8/attachment.html>