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

[Duncan Sands]

Hi Chris,

>> 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.

the basic idea is that you recursively visit all uses of the original value, and
if none of them is returned and none stored somewhere, then you decree that the
value was not captured.  This is wrong in the sense that there are a bunch of
crazy examples for which this definition gives "not captured" but in fact the 
original pointer value managed to escape.  All of these crazy examples (I gave
one in my previous email) are based on "reconstruction via control flow", though
perhaps "correlated expressions" is a better name: you inspect the original
value and branch based on the values seen, for example you inspect each bit and
branch depending on whether it is 0 or 1; in the branched to basic blocks you
build up a new value, unconnected to the original by any def-use chain, for
example by or'ing in 0 or 1 depending which block was branched to.  In this way
you can reconstruct the original value in some other register without having any
connection via uses between the registers.

Anyway, I whipped up a quick implementation of this, see attached patch.  It
is a bit more complicated than what I said above because loading the pointer
and returning the loaded value is not considered to capture it.  Also, to please
Dan, it allows stores to alloca's and tracks what happens to the alloca.  It is
much more liberal than what we had before, however it does do less well in two
cases: previously if the pointer was a phi node operand or the operand of a
select, then we would not consider returning a load of the phi/select pointer to
be a capture, but now we do.  That's because it's not immediately clear to me
how to handle these cases better in this context.

The results are disappointing.  Running on MultiSource results in a 0.7%
increase in the number of function parameters consider nocapture (18523
compared to 18393).  For many programs the number of nocapture parameters
went down, presumably due to the select/phi issue I mentioned above.

Ciao,

Duncan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: capture.diff
Type: text/x-patch
Size: 8693 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20091124/53b2a372/attachment.bin>