[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

[Nick Lewycky]

Dan Gohman wrote:
>
> On Jun 30, 2010, at 9:21 PM, Chris Lattner wrote:
>
>> On Jun 29, 2010, at 11:09 AM, Dan Gohman wrote:
>>>> 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.
>>
>> 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.
>
> 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 believe you. From the LangRef.html#paramattrs

"*noalias:* This indicates that the pointer does not alias any global or 
any other parameter. The caller is responsible for ensuring that this is 
the case. ..."

Nick