[llvm-commits] [llvm] r59940 - in /llvm/trunk: docs/LangRef.html lib/Analysis/BasicAliasAnalysis.cpp

Nick Lewycky nicholas at mxc.ca
Sun Nov 23 23:55:37 PST 2008


Török Edwin wrote:
> On 2008-11-24 09:43, Nick Lewycky wrote:
>> Török Edwin wrote:
>>   
>>> On 2008-11-24 07:00, Nick Lewycky wrote:
>>>     
>>>> Author: nicholas
>>>> Date: Sun Nov 23 23:00:44 2008
>>>> New Revision: 59940
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=59940&view=rev
>>>> Log:
>>>> Seriously strengthen the guarantee offered by noalias on a function's return
>>>> value. It must now be as if the pointer were allocated and has not escaped to
>>>> the caller. Thanks to Dan Gohman for pointing out the error in the original
>>>> and helping devise this definition.
>>>>
>>>>   
>>>>       
>>> malloc(0) is allowed to return a unique pointer, instead of NULL.
>>> Does this code handle that?
>>>     
>> Sure, a noalias function can return NULL or a unique pointer. Returning 
>> NULL is sufficient to not alias.
>>
>>   
> 
> Agreed about NULL.
> However if I call the function twice, and it returns the same pointer
> (which is unique, but same for both calls), doesn't that mean
> that the return value aliases a caller visible pointer?

Oh I see what you mean.

I hadn't thought of that, but since you can't actually store a byte 
there, it should be treated just like NULL case.

Feel free to patch the LangRef, or else I'll get to it later tomorrow.

Similarly, there's the case of:
   p1 = malloc(1)
   free(p1)
   p2 = malloc(1)
p1 could equal p2, but they don't alias since the object pointed to has 
been destroyed.

"Aliasing" in general is not defined in the LangRef. Perhaps we'll need 
to do that in order to elucidate the intended behaviour in all of these 
corner cases.

Nick




More information about the llvm-commits mailing list