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

[Duncan Sands]

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.  Consider the following standard crazy example
of capturing a pointer P.  This is a prime example where the pointer was
captured via control flow:

   n = 0
   loop:
     Q = GEP P, -n
     if (Q == null)
       break;
     n = n + 1;
     goto loop;
   captured_value = GEP null, n

Notice how if you start with "captured_value", and look at how it is defined you
see it is defined in terms of null and "n" via a GEP.  "n" itself is defined in
terms of "n" and 0 via a PHI node.  Nowhere do you see the original pointer P.
Using my proposed definition here we would say that P is *not* captured.  What
do you think?

Doing such a thing introduces an 'abstraction penalty' where malloc wrappers now 
get pessimized where direct calls to malloc don't.

A malloc wrapper should also be marked noalias, so your argument seems weak :)
Of course currently we have no pass that can deduce noalias attributes, which
would help here.

Ciao,

Duncan.