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

[Philip Reames via llvm-commits]

On 08/20/2016 12:56 PM, Daniel Berlin wrote:
> 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.
Like I said, haven't been following along.  This is a lot better 
progress than I'd realized and greatly diminishes my concern,
>
> 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?
If we already have MemorySSA on by default, I think you've already 
passed the threshold I was most worried about.  There's a huge 
difference between "we've got this new thing which which solve all 
problems, but isn't yet available", and "we've got this new thing which 
is already in use and we need to port this to".

>
>
> On Sat, Aug 20, 2016 at 12:54 PM, Philip Reames 
> <listmail at philipreames.com <mailto: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
>         <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/a69d8e6e/attachment.html>