[llvm-dev] Propagating noalias annotation

[Hal Finkel via llvm-dev]

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>