[llvm-commits] [llvm] r89421 - /llvm/trunk/lib/Analysis/CaptureTracking.cpp

[Chris Lattner]

On Nov 23, 2009, at 6:22 AM, Duncan Sands wrote:
> Hi Chris,
> 
>>>>> I think this is wrong, consider the following pseudocode example:
>>>> While this example is "possible" I really don't think this is worth worrying about.  It is not valid C code, is not likely to exist in practice, etc.  Beyond that, comparison against null is really common and we really do want "nocapture" in this cases.
>>> well, it's a slippery slope :)  Dan later changed this to only allow
>>> comparisons against malloc return values and other noalias function
>>> results.
>> Is such paranoia really worthwhile?
> 
> I'm not against loosening the definition of nocapture as long as it is clearly
> defined what nocapture means.  I think the obvious thing to do is to say that
> if the value of the pointer is reconstructed *entirely by control flow* then it
> is not considered to be captured.

That works for me, though I'm not sure exactly what it means.

>  Consider the following standard crazy example
> of capturing a pointer P.

Yes, I'm aware of things like that, I just don't care about them ;-)

> 
> Using my proposed definition here we would say that P is *not* captured.  What
> do you think?

That sort of thing should definitely not be supported.  Can you propose wording to add to langref to codify how nocapture should work here?

-Chris