[llvm-dev] Existing studies on the benefits of pointer analysis

Chris Lattner via llvm-dev llvm-dev at lists.llvm.org
Sun Mar 27 22:37:45 PDT 2016


> On Mar 25, 2016, at 9:04 PM, Jia Chen <jchen at cs.utexas.edu> wrote:
> 
> On 03/25/2016 08:08 PM, Chris Lattner wrote:
>> I’m still a big fan of context sensitive, flow insensitive, unification based models.  
> 
> Interestingly I find the unification approach quite unsatisfactory sometime. What happens there is pointers with the same "depth" are too often clobbered together unless they are really unrelated to each other. 
> 
>> Contrary to your claim, context sensitivity *is* useful for mod-ref analysis, e.g. “can I hoist a load across this call”?  Context sensitivity improves the precision of the mod/ref set of the call.
>> 
> I'm not sure about that. How often does mod-ref information change across callsites? Isn't a good context-insensitive function summary good enough?

It changes all the time.  Here’s a trivial example, assume no inlining and no AA other than the one in question:

std::vector<int> V1 = { 1, 2, 3 };
std::vector<int> V2 = { 4, 5, 6 };

V1.pop_back();    // Mutates *this

auto length = V1.size();

V2.pop_back();    // Mutates *this

auto zero = length - V1.size()

In this case, the compiler should “obviously” be able to CSE length, allowing further simplification to substitute zero with 0.

However, with a context sensitive AA, both &V1 and &V2 end up aliasing the “this” pointer in std::vector::pop_back.  As such, without context sensitivity, you would falsely assume that “V2.pop_back();” could modify “V1”.  This is unfortunate, particularly for OO languages that frequently use static dispatch (like C++, Swift, and others).


That said, I have no idea what you’re referring to by "context-insensitive function summary”.  If you’re talking about something context sensitive, then ya, it can handle this.  :-)

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160327/0b312a81/attachment.html>


More information about the llvm-dev mailing list