<div dir="ltr">This is basically what this patch does - but in a way that keeps all of the interfaces of AliasSet and AliasSetTracker consistent.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 11, 2016 at 4:00 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Aug 11, 2016 at 3:44 PM, Michael Kuperstein <span dir="ltr"><<a href="mailto:mkuper@google.com" target="_blank">mkuper@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">mkuper created this revision.<br>
mkuper added reviewers: davidxl, dberlin.<br>
mkuper added a subscriber: llvm-commits.<br>
<br>
The cause of PR28832 is the quadratic behavior of repeated inserts into AliasSetTracker - inserting a pointer into AST is linear, since it requires walking over all "may" alias sets, and running an alias check vs. each pointer in such a set.<br>
This patch tracks (more or less) the total number of pointers in all "may" sets, and when that number exceeds a threshold, declares the tracker "saturated" - and lumps all pointers into a single "may" set.<br>
<br>
For the example in PR28832, without this patch, I have:<br>
---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---<br>
43.4251 ( 47.4%) 0.0440 ( 33.2%) 43.4691 ( 47.4%) 43.4471 ( 47.4%) Loop Invariant Code Motion<br>
19.6565 ( 21.5%) 0.0040 ( 3.0%) 19.6605 ( 21.5%) 19.6512 ( 21.5%) Loop Invariant Code Motion<br>
17.5580 ( 19.2%) 0.0040 ( 3.0%) 17.5620 ( 19.2%) 17.5534 ( 19.2%) Loop Invariant Code Motion<br>
3.0498 ( 3.3%) 0.0080 ( 6.0%) 3.0578 ( 3.3%) 3.0563 ( 3.3%) Value Propagation<br>
<br>
And with this patch, with a threshold of 250:<br>
---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---<br>
5.6446 ( 29.1%) 0.0160 ( 5.6%) 5.6606 ( 28.8%) 5.6570 ( 28.8%) Value Propagation<br>
2.2423 ( 11.6%) 0.0040 ( 1.4%) 2.2463 ( 11.4%) 2.2448 ( 11.4%) Loop Invariant Code Motion<br>
1.6510 ( 8.5%) 0.0039 ( 1.4%) 1.6549 ( 8.4%) 1.6526 ( 8.4%) Loop Invariant Code Motion<br>
1.5398 ( 8.0%) 0.0040 ( 1.4%) 1.5438 ( 7.9%) 1.5429 ( 7.9%) Loop Invariant Code Motion<br>
<br>
A threshold of 1000 produces a significant slowdown:<br>
---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---<br>
10.0644 ( 25.7%) 0.0080 ( 2.4%) 10.0724 ( 25.5%) 10.0689 ( 25.5%) Loop Invariant Code Motion<br>
7.5912 ( 19.4%) 0.0159 ( 4.8%) 7.6071 ( 19.3%) 7.6063 ( 19.3%) Loop Invariant Code Motion<br>
7.4471 ( 19.0%) 0.0120 ( 3.6%) 7.4591 ( 18.9%) 7.4571 ( 18.9%) Loop Invariant Code Motion<br>
5.5252 ( 14.1%) 0.0200 ( 6.0%) 5.5452 ( 14.1%) 5.5454 ( 14.1%) Value Propagation<br>
<br>
This isn't in a committable state - it needs some cleanup, more testing, and some substantive fixes (per the TODOs).<br>
So no point in reviewing it in detail yet, but I'd like to get a direction check.<br>
<br>
Danny, w.r.t to our earlier discussion - I'm not a fan of the idea of having a saturated AST be unsafe to query, so this is required anyway. </blockquote><div><br></div></div></div><div>Yup.</div><div><br></div><div>IMHO, you should always just return "may-alias" to any query once saturated :P.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We can add isSaturated() checks to LICM to speed it up further, as a separate patch.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D23432" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2343<wbr>2</a><br>
<br>
Files:<br>
include/llvm/Analysis/AliasSet<wbr>Tracker.h<br>
lib/Analysis/AliasSetTracker.c<wbr>pp<br>
test/Analysis/AliasSet/saturat<wbr>ion.ll<br>
<br>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div>