[llvm-dev] Propagating noalias annotation

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Fri Nov 17 07:10:41 PST 2017


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>


More information about the llvm-dev mailing list