[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 1, 2010, at 2:29 PM, Dan Gohman wrote:
>>> "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.
>>> 
>> 
>> I don't buy this at all.  The current interface to AA (even for interprocedural clients) is context insensitive.  If you want a path or context-sensitive query interface, you'd need a substantially richer and more complex (aka slower) interface.  DSA provides this sort of interface for example.
> 
> You're right, I was mistaken about recursive functions; that's a class of
> cases which are a lot more complicated and do bring in context sensitivity
> concerns. I've removed these considerations in r107420.

Thanks.  I'm still confused about why we need a separate pass for IPA basicaa...

> 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.

That said, I completely believe that it would be invalid for an interprocedural client to infer properties in a caller of a function with no-alias based on the no-alias properties in the callee.  This is separate from reporting on queries scoped to the callee though.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20100704/472b616a/attachment.html>