<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote id="DWT1341" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Jia Chen via llvm-dev" <llvm-dev@lists.llvm.org><br><b>To: </b>"Chris Lattner" <clattner@apple.com><br><b>Cc: </b>"llvm-dev" <llvm-dev@lists.llvm.org><br><b>Sent: </b>Monday, March 28, 2016 10:10:12 AM<br><b>Subject: </b>Re: [llvm-dev] Existing studies on the benefits of pointer analysis<br><br>
<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">
<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: 0pt 0pt 0pt 40px; border: medium 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></blockquote>Can you elaborate on what you mean by flow sensitive? We have a mod/ref query interface that can return answers specific to a particular instruction/call pair. The code above could easily live in a single basic block, and if we had function attribute deduction on the 'argmemonly' attribute, we could probably do this now.<br><br> -Hal<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;">
<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>
<br>_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br>http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br></blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>