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

[Daniel Berlin via llvm-commits]

Even if you kept the ASTracker concept for some reason, moving the
ASTracker to MemorySSA also would make it scale significantly better (let's
ignore the updating through IR changes part for a second, as it's
orthogonal)

For MemorySSA, ASTracker stores only clobbering MemoryAccesses as a
SmallPtrSet.

For adding a load, you add MSSA->getClobberingMemoryAccess(load) (this is
only necessary if memoryssa gave up optimizing uses, we could fix this.
Otherwise it's just the defining access of the load)
For adding a store, you add the store.

For merging, you merge the sets.
For querying for loads, you see if MSSA->getClobberingMemoryAccess(load) is
in the set (ditto the above)
for querying for stores, you see if the store, or
 MSSA->getClobberingMemoryAccess(store) is in the set.

This will scale at least a factor of N better.

On Sat, Aug 20, 2016 at 12:38 PM, Hal Finkel <hfinkel at anl.gov> 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.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D23432
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160820/cc510e5a/attachment.html>