[llvm-commits] [llvm] r107109 - in /llvm/trunk: include/llvm/Analysis/AliasAnalysis.h include/llvm/Analysis/Passes.h lib/Analysis/AliasAnalysis.cpp lib/Analysis/BasicAliasAnalysis.cpp test/Analysis/BasicAA/interprocedural.ll

[Dan Gohman]

On Jun 28, 2010, at 10:22 PM, Nick Lewycky wrote:

> Dan Gohman wrote:
>> Author: djg
>> Date: Mon Jun 28 19:50:39 2010
>> New Revision: 107109
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=107109&view=rev
>> Log:
>> Add an Intraprocedural form of BasicAliasAnalysis, which aims to
>> properly handles instructions and arguments defined in different
>> functions, or across recursive function iterations.
> 
> Dan,
> 
> Why is this an additional pass? Why not infer Interprocedural from SameParent()? The idempotents that basicaa was testing for should still hold true whenever SameParent() is true. It looks like the 'Interprocedural BasicAA' is basically a bugfix on BasicAA.

"noalias" is only meaningful from a single-procedure perspective.
For example:

@G = external global i32
define void @foo(i32* noalias %p) {
  ...
}
...
  call void @foo(i32* @G)

If you're working exclusively within the body of @foo, then alias(@G, %p)
can be NoAlias. From an interprocedural perspective, it can be MustAlias.
Even with something like

define void @bar(double* noalias %a, double* noalias %b) {

it isn't trivial to say that %a doesn't alias %b because if it goes on to do

  call void @bar(double* %b, double* %a)

then there is a sense in which %a could MustAlias %b, interprocedurally.

Then there's "arguments can't alias allocas" logic. From a non-interprocedural
perspective, this works. From an interprocedural perspective, consider
function r0 in the included testcase.

With extra analysis, InterproceduralBasicAliasAnalysis could get more
precise answers. The current code is just an initial effort.

Another interesting thing to consider is that the current alias API
doesn't provide a way to specify the scope to consider for potential
aliasing.

Dan