llvm dev - Jun 2010 - [LLVMdev] AliasAnalysis Documentation Ambiguity

Hi,

The description of the alias method in AliasAnalysis reads:

alias - The main low level interface to the alias analysis implementation.
Returns a Result indicating whether the two pointers are aliased to each other.
This is the interface that must be implemented by specific alias analysis
implementations.

This implies that alias can run on ANY two Values without restrictions. However,
line 696 of BasicAliasAnalysis reads:

// Arguments can't alias with local allocations or noalias calls.
if ((isa<Argument>(O1) && (isa<AllocaInst>(O2) ||
isNoAliasCall(O2))) ||
    (isa<Argument>(O2) && (isa<AllocaInst>(O1) ||
isNoAliasCall(O1))))
  return NoAlias;

This reasoning is only valid if the Argument and the AllocaInst or NoAliasCall
in question are part of the same function. Here is an example:

void foo(int *bar) {
}

void baz(void) {
 int qux[10];
 foo(qux);
}

In the above example, qux in baz MayAlias with bar in foo. However,
BasicAliasAnalysis will return NoAlias.

Should there be a check in BasicAliasAnalysis to ensure that O1 and O2 belong to
the same function, or should the documentation be updated to indicate the limits
of the alias method? Thanks.

Tom

On Jun 9, 2010, at 11:35 AM, "Thomas B. Jablin" <tjablin at
cs.princeton.edu
 > wrote:
>
> Should there be a check in BasicAliasAnalysis to ensure that O1 and  
> O2 belong to the same function, or should the documentation be  
> updated to indicate the limits of the alias method? Thanks.
I think there should be such a check.

A noalias Argument should still be NoAlias with Allocas in other  
functions, but a regular Argument should be MayAlias with them -- at  
least for the level of analysis that BasicAA does.

The noalias case is interesting though.  If you're doing extensive  
interprocedural analysis, it may be necessary to add a way to tell  
AliasAnalysis passes to completely ignore noalias.

Dan
>