[llvm-commits] [llvm] r40624 - in /llvm/trunk: lib/Analysis/BasicAliasAnalysis.cpp test/Analysis/BasicAA/2007-07-31-NoAliasTest.ll

[Daniel Berlin]

On 7/31/07, Dan Gohman <djg at cray.com> wrote:
> > Log:
> > Teach BasicAA about noalias function parameters. Passes all of DejaGNU and test-suite.
>
> I just grepped through LLVM's test-suite and didn't find any uses of the
> restrict keyword though...
>

There are a few you could snag from GCC's testsuite, because we
started with an implementation that had the exact same problems you've
noted below.


> So for an alias query where one of the two pointers is noalias and the
> other is not, and the non-noalias one doesn't have a base object that
> basicaa can find, the answer should be MayAlias. A more advanced pass
> could try to prove that the non-noalias pointer couldn't possibly be
> "based on" the noalias one by examining all its uses, though the specific
> example here would defy such analysis.

This is also what we eventually did with GCC.

Note that your function call example is not just "not disallowed", it
is explicitly allowed.  It is the one case you are allowed to carry
restricted pointers outside the block they are in.

See C99 6.7.3.1 #12

There is a weird issue in restrict where  gcc doesn't "check for
correctness of input code", and i doubt LLVM can either (at least, not
easily).  This is that block nesting can introduce valid restricted
pointers in the nested block that would have otherwise been invalid.
IIRC, anyway :)

We of course, eliminate lexical scoping.  For safety sake, we just
assume that if they have come up with assignments between restricted
pointers, that they are legal.