[llvm-commits] patch: make gvn a little pickier about nocapture

Nick Lewycky nicholas at mxc.ca
Mon Nov 7 11:25:03 PST 2011


This patch addresses a failure-to-devirtualize case that GCC handles. 
Long story short, the problem is that GVN looks at a load of an alloca 
and queries MemDep who walks upwards and finds a function call with no 
arguments. When MemDep asks BasicAA whether it could alias the alloca, 
BasicAA determines that the alloca escapes and concludes that the callee 
could modify it. The reality is that the pointer hasn't escaped yet at 
this point in the program, it only escapes some time after the call.

The fix in this patch comes in two ugly parts.

First I refactor PointerMayBeCaptured to take an object that it informs 
of the captures, and gives it the opportunity to prune the search. This 
isn't the prettiest design ever (the function is now templated and 
implemented in the header), but I think it's the right trade-off. The 
existing API is preserved and causes one instantiation inside 
CaptureTracking.cpp where it always used to be.

Second I copy+paste part of basicaa's logic for analyzing ModRef of 
calls into MemDep, and replace its use of isNonEscapingLocalObject() 
with my own smarter capture logic that uses a DominatorTree. We can't 
put this logic inside basicaa because it requires a linear scan over the 
list of instructions. We could add a new "capture tracker" argument to 
the AA interface, but it doesn't make sense for any AA impl except 
basicaa. We could add a method to basicaa and have memdep hand it a 
pointer to the CaptureTracking callback object, but it's possible that 
would conflict with another basicaa user who wants to do the same. The 
other reasonable approach I can think of is adding a new AA pass.

All that said, please review! This fixes inline-devirt-{1,2,8}.C in PR8886.

Nick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rle-escape-1.patch
Type: text/x-patch
Size: 18922 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20111107/2a01298d/attachment.bin>


More information about the llvm-commits mailing list