[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 clattner at apple.com
Wed Jun 30 21:21:17 PDT 2010


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.

To be clear, alias(a,b) is always no-alias since the arguments are "no-alias" and they are in the same function.  no-alias clearly doesn't apply if the pointers are in different functions.

> Then there's "arguments can't alias allocas" logic. From a non-interprocedural
> perspective, this works. From an interprocedural perspective, consider
> function r0 in the included testcase.

Again, this is only true if AA were a context or path sensitive interface, but it isn't.  GlobalModRef is an example of a context sensitive analysis which is queried with a context insensitive interface.  DSA (in the poolalloc module) is another.  To be able to do context sensitive queries, you have to be able to pass information into the clients.  I am pretty sure that I covered this in my phd thesis if you care.

> Another interesting thing to consider is that the current alias API
> doesn't provide a way to specify the scope to consider for potential
> aliasing.

Right, and it shouldn't IMO because it is a) very expensive to express and b) completely uninteresting for most clients.  If we wanted to handle context sensitive queries, we should add a new ContextSensitiveAA interface or something.

-Chris



More information about the llvm-commits mailing list