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

[Daniel Berlin via llvm-commits]

It is already enabled by default for GVNHoist, which is enabled by default
at O1 and O2.
There are patches in progress to convert other passes under review.

We just branched for 3.9, and are in the midst of significant pass manager
work, so i am not sure having a super-near term date makes sense?


On Sat, Aug 20, 2016 at 12:54 PM, Philip Reames <listmail at philipreames.com>
wrote:

> On 08/20/2016 12:38 PM, Hal Finkel wrote:
>
>> hfinkel added a comment.
>>
>> In https://reviews.llvm.org/D23432#521624, @reames wrote:
>>
>> 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?
>>>
>>
>> My understanding from the discussion is that all uses of the ASTracker
>> are going to be replaced with MemorySSA-based algorithms; that is why I was
>> okay with this (for now). If we still need an AST concept, then we'll want
>> to do something more sophisticated.
>>
> I haven't been following the MemorySSA work recently.  Do we have a
> concrete near term date in mind for enabling MemorySSA?  If not, I am not
> okay with an attitude of "MemorySSA will fix everything... someday".
> That's a very dangerous road to start walking down.
>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160820/6de3b921/attachment.html>