[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