[llvm-dev] llvm 3.9 Alias Analysis result for function's by-ref arguments

[Hal Finkel via llvm-dev]

On 03/29/2017 11:47 AM, Hayrapetyan, Anahit wrote:
>
> Thanks for the quick response.
>
>
> I tried what you’ve suggested, that is making function arguments 
> noalias. However the result is still the same.
>
>
> If it may help here are sample function and its IR:
>
> void swap (int* restrict n, int* restrict m)
>
> {
>
>    int tmp = 9;
>
>    *n = tmp;
>
>    *m = 5;
>
> }
>
>
> ; Function Attrs: nounwind uwtable
>
> define void @swap(i32* noalias %n, i32* noalias %m) #0 {
>
> entry:
>
>  %n.addr = alloca i32*, align 8
>
>  %m.addr = alloca i32*, align 8
>
>  %tmp = alloca i32, align 4
>
>  store i32* %n, i32** %n.addr, align 8
>
>  store i32* %m, i32** %m.addr, align 8
>
>  store i32 9, i32* %tmp, align 4
>
>  %0 = load i32, i32* %tmp, align 4
>
>  %1 = load i32*, i32** %n.addr, align 8
>
>  store i32 %0, i32* %1, align 4
>
>  %2 = load i32*, i32** %m.addr, align 8
>
>  store i32 5, i32* %2, align 4
>
>  ret void
>
> }
>

This looks like unoptimized IR. You'll need to run some optimization 
passes first to get reasonable AA output. mem2reg/SROA, 
InstSimplify/InstCombine, etc.

  -Hal

>
>
> In getAnalyisisUsage function of my pass I have
>
> AU.setPreservesAll();
>
> AU.addRequired<llvm::TargetLibraryInfoWrapperPass>();
>
> AU.addRequired<llvm::AssumptionCacheTracker>();
>
> AU.addRequired<llvm::AAResultsWrapperPass>();
>
> llvm::getAAResultsAnalysisUsage(AU);
>
>
> And I get the AAResults by
>
> llvm::AAResults& AAR = 
> getAnalysis<llvm::AAResultsWrapperPass>().getAAResults();
>
>
> I also tried running just llvm alias analysis and print alias sets. 
> The arguments are in the same alias set.
>
>
> opt -aa -print-alias-sets simple.bc -o out.bc
>
>
> Pointers: (i32* %1, 4), (i32* %2, 4)are in the same set, where %1 is 
> load for n and %2 is load for m.
>
>
> Could you please explain why I’m still getting the same results or if 
> there is something that I’m doing wrong?
>
>
> Thanks,
>
> Anahit.
>
> ------------------------------------------------------------------------
> *From:* Hal Finkel <hfinkel at anl.gov>
> *Sent:* Tuesday, March 28, 2017 11:29 PM
> *To:* Hayrapetyan, Anahit; llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] llvm 3.9 Alias Analysis result for 
> function's by-ref arguments
>
>
> On 03/28/2017 04:32 AM, Hayrapetyan, Anahit via llvm-dev wrote:
>>
>> Hi,
>>
>>
>> I’m writing an analysis pass which is supposed to find instructions 
>> in a function that modify function’s by-ref arguments. For that I’m 
>> using llvm AliasAnalysis pass, particularly querying for ModRef info 
>> for instructions and function arguments, to see if a given 
>> instruction modifies a given argument. However, for functions with 
>> more than one by-ref argument, I get strange results. Instructions, 
>> which modify one of the arguments, are reported as modifying the 
>> others too - saying, ModRef info of those instructions is Mod for all 
>> arguments.
>>
>> For this example
>>
>>     /void function(int& n, int& m)/
>>
>>     /{/
>>
>>     /int tmp = m;/
>>
>>     /n = tmp;/
>>
>>     /}/
>>
>> Arguments /n/ and /m/ are marked as MayAlias, and storing /tmp/ into 
>> /n/ is reported to modify /m/ too.
>>
>>
>> I found a few discussions about this problem. In one of them, it was 
>> suggested to use cfl-aa, I tried it and it did not solve the problem.
>>
>> In another one they said that this happens on purpose. llvm Alias 
>> Analysis marks function’s by-ref arguments MayAlias, as function may 
>> be called with arguments referencing the same variable.
>>
>> So I would like to ask whether this is the case.
>>
>
> Yes, this is the case.
> It is legal to call the function as:
>
>   int a = ...;
>   function(a, a);
>
> And so we need to make a conservative assumption.
>
>> And if it is, is there a way to make llvm ignore this consideration?
>>
>
> Yes, if you add __restrict__ (noalias as the IR level), then we'll 
> assume they don't alias.
>
>  -Hal
>
>> Thanks,
>>
>> Anahit.
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20170330/2adc3392/attachment.html>