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

[Hal Finkel via llvm-dev]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170328/7fef5dd7/attachment.html>