On 7/31/07, Dan Gohman <[EMAIL PROTECTED]> 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. _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
