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

[Christopher Lamb]

Daniel,

I'm not a GCC guru, so I had some problems picking up the restrict  
qualifiers for argument types in llvm-gcc's type conversion routines.  
It seems that for C the qualifier is kept with the argument type, but  
in C++ it's only available in the declaration and is not kept with  
the types. Is there a better/proper way to get access to these  
qualifiers?

--
Chris

On Jul 31, 2007, at 8:27 AM, Daniel Berlin wrote:

> 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.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

--
Christopher Lamb



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20070731/7f23004e/attachment.html>