[PATCH] D23432: [AliasSetTracker] Degrade AliasSetTracker results when may-alias sets get too large.

[Michael Kuperstein via llvm-commits]

This is basically what this patch does - but in a way that keeps all of the
interfaces of AliasSet and AliasSetTracker consistent.

On Thu, Aug 11, 2016 at 4:00 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

>
>
> On Thu, Aug 11, 2016 at 3:44 PM, Michael Kuperstein <mkuper at google.com>
> wrote:
>
>> mkuper created this revision.
>> mkuper added reviewers: davidxl, dberlin.
>> mkuper added a subscriber: llvm-commits.
>>
>> 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.
>> 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.
>>
>> For the example in PR28832, without this patch, I have:
>>    ---User Time---   --System Time--   --User+System--   ---Wall Time---
>> --- Name ---
>>   43.4251 ( 47.4%)   0.0440 ( 33.2%)  43.4691 ( 47.4%)  43.4471 ( 47.4%)
>> Loop Invariant Code Motion
>>   19.6565 ( 21.5%)   0.0040 (  3.0%)  19.6605 ( 21.5%)  19.6512 ( 21.5%)
>> Loop Invariant Code Motion
>>   17.5580 ( 19.2%)   0.0040 (  3.0%)  17.5620 ( 19.2%)  17.5534 ( 19.2%)
>> Loop Invariant Code Motion
>>    3.0498 (  3.3%)   0.0080 (  6.0%)   3.0578 (  3.3%)   3.0563 (  3.3%)
>> Value Propagation
>>
>> And with this patch, with a threshold of 250:
>>    ---User Time---   --System Time--   --User+System--   ---Wall Time---
>> --- Name ---
>>    5.6446 ( 29.1%)   0.0160 (  5.6%)   5.6606 ( 28.8%)   5.6570 ( 28.8%)
>> Value Propagation
>>    2.2423 ( 11.6%)   0.0040 (  1.4%)   2.2463 ( 11.4%)   2.2448 ( 11.4%)
>> Loop Invariant Code Motion
>>    1.6510 (  8.5%)   0.0039 (  1.4%)   1.6549 (  8.4%)   1.6526 (  8.4%)
>> Loop Invariant Code Motion
>>    1.5398 (  8.0%)   0.0040 (  1.4%)   1.5438 (  7.9%)   1.5429 (  7.9%)
>> Loop Invariant Code Motion
>>
>> A threshold of 1000 produces a significant slowdown:
>>    ---User Time---   --System Time--   --User+System--   ---Wall Time---
>> --- Name ---
>>   10.0644 ( 25.7%)   0.0080 (  2.4%)  10.0724 ( 25.5%)  10.0689 ( 25.5%)
>> Loop Invariant Code Motion
>>    7.5912 ( 19.4%)   0.0159 (  4.8%)   7.6071 ( 19.3%)   7.6063 ( 19.3%)
>> Loop Invariant Code Motion
>>    7.4471 ( 19.0%)   0.0120 (  3.6%)   7.4591 ( 18.9%)   7.4571 ( 18.9%)
>> Loop Invariant Code Motion
>>    5.5252 ( 14.1%)   0.0200 (  6.0%)   5.5452 ( 14.1%)   5.5454 ( 14.1%)
>> Value Propagation
>>
>> This isn't in a committable state - it needs some cleanup, more testing,
>> and some substantive fixes (per the TODOs).
>> So no point in reviewing it in detail yet, but I'd like to get a
>> direction check.
>>
>> 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.
>
>
> Yup.
>
> IMHO, you should always just return "may-alias" to any query once
> saturated :P.
>
>
>> We can add isSaturated() checks to LICM to speed it up further, as a
>> separate patch.
>>
>>
>> https://reviews.llvm.org/D23432
>>
>> Files:
>>   include/llvm/Analysis/AliasSetTracker.h
>>   lib/Analysis/AliasSetTracker.cpp
>>   test/Analysis/AliasSet/saturation.ll
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160811/1c7d6300/attachment.html>