[llvm-dev] Propagating noalias annotation

[Hongbin Zheng via llvm-dev]

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>