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

[Philip Reames via llvm-commits]

On 08/20/2016 10:14 PM, Xinliang David Li wrote:
> I understand your concern here, and  performance cliff is definitely
> something we should try to avoid. However dropping alias info in
> situation like this != performance cliff.  I am sure we can come up
> with hand-created examples to show  performance damage with dropped
> alias info, in real programs, when a function reaches such a state,
> the alias query results will be already so conservative that doing
> memory disambiguation busily any further will likely be just waste of
> compile time, so 'gracefully' lowering alias precision or dropping
> aliasing info to the floor makes no difference practically.  I have
> not seen performance regressions due to the use of cutoff limits
> elsewhere in LLVM.
I have.  In fact, we have a number of the flags tuned higher in our 
local builds than upstream precisely for this reason.
>
> David
>
>
> On Sat, Aug 20, 2016 at 12:24 PM, Philip Reames
> <listmail at philipreames.com> wrote:
>> reames added a subscriber: reames.
>> reames added a comment.
>>
>> I am not actively objecting to this patch, but I really don't like the overall direction here.  Having a threshold where our ability to optimize falls off a cliff just seems really undesirable.  As Hal pointed out, there are likely options for summarizing alias sets to allow quicker AA queries.  How much have we explored that design space?
>>
>>
>> Repository:
>>    rL LLVM
>>
>> https://reviews.llvm.org/D23432
>>
>>
>>