[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