<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 03/28/2016 12:37 AM, Chris Lattner
wrote:<br>
</div>
<blockquote
cite="mid:B017C534-9BF7-4C40-B2DF-A6BA3790C356@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div>It changes all the time. Here’s a trivial example, assume no
inlining and no AA other than the one in question:</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class="">std::vector<int> V1 = { 1, 2, 3 };</div>
<div class="">
<div class="">std::vector<int> V2 = { 4, 5, 6 };</div>
</div>
<div class=""><br class="">
</div>
<div class="">V1.pop_back(); // Mutates *this</div>
<div class=""><br class="">
</div>
<div class="">auto length = V1.size();</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">V2.pop_back(); // Mutates *this</div>
</div>
<div class=""><br class="">
</div>
<div class="">auto zero = length - V1.size()</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">In this case, the compiler should “obviously” be
able to CSE length, allowing further simplification to
substitute zero with 0.</div>
<div class=""><br class="">
</div>
<div class="">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).</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">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.
:-)</div>
<br>
</blockquote>
For the example to work here the CSE pass itself needs to be
flow-sensitive and context-sensitive. I don't think that's how most
optimizations in LLVM work. If it is, then I agree with all you
said. But if it isn't, there's no point in bumping up the context
sensitivity just for the pointer analysis.<br>
<br>
As Daniel mentioned earlier in this thread, the analysis analysis
framework in LLVM doesn't provide any APIs for flow-sensitive
queries as well as context-sensitive queries. This design choice
almost eliminate any possibilities for a flow-sensitive or
context-sensitive pointer analysis to be useful. Strangely, the set
of APIs does support 1-CFA context-sensitive mod-ref queries (so I
guess one could somehow reap some context-sensitive benefits out of
them after all). To me that design incoherence looks confusing, but
I'm pretty sure you know much better than me why it should work that
way :)<br>
<br>
<br>
- Jia<br>
</body>
</html>