[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

[Chris Lattner]

On Jul 6, 2010, at 5:16 PM, Dan Gohman wrote:

>>> However, beyond classic path and context scoping, there's another sense of
>>> scope that an alias query can have, the scope of a noalias keyword. noalias
>>> on an argument indicates that argument's relationship with other pointers
>>> within that function, but it isn't meaningful when considering pointers
>>> from an interprocedural perspective. An example of this is this is the first
>>> example I gave above, with alias(@G, %p).
>> 
>> I don't understand this.  The interface provided by AliasAnalysis (which is independent of whether the implementation uses IP information or not) assumes the client is a) asking about relations between globals, or b) is in the context of a function.
>> 
>> In the first example above, alias(@G, %p) is false whether the implementation is single or interprocedural.  Because the client is asking about "p", the query is implicitly scoped to the body of the function.
>> 
>> The AliasAnalysis *interface* has this implicit scoping.  The treatment of noalias *cannot* be semantically different between two different implementations of AliasAnalysis, because the clients haven't changed.  The contract of the AliasAnalysis interface is fixed.
> 
> You right though, AliasAnalysis API implementations shouldn't have
> differing semantics. I'll probably remove interprocedural-basic-aa
> to resolve this, since I don't have a present practical use case
> for it.

Sounds good.  It's good to raise these issues, and even better to document them well so that clients of the AA interface know what to expect.  Thanks Dan,

-Chris