[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