[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 Jul 4, 2010, at 10:23 AM, Chris Lattner wrote:

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

It was useful as a theoretical reference point, to help define noalias
and NoAlias better, at least. With the new wording in place now, it's
a coherent concept.

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

Dan