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

[Daniel Berlin via llvm-commits]

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

> On 08/20/2016 12:59 PM, Daniel Berlin wrote:
>
> 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.
>
> You seem to have interpreted my comment as arguing against MemorySSA.
>

Nope, but sorry if it came off that way :)
I'm arguing in general that it's not a slippery slope, because you already
fell down the slope. :)
(I'll address this one in either email).

In this one, i'm just pointing out if we either like this abstraction, or
want some intermediate point that doesn't require only using memoryssa, we
could simply port this abstraction without a ton of trouble.

(in fact, it's easier that i said, you don't actually have to do anything
for adding a load, you only ever have to add MemoryDef's).



> That was not my intent at all.  If we have a realistic chance of porting
> to MemorySSA in the near term (and from your other response, it sounds like
> we do), then that's definitely the right direction to move in.
>
>
> 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/ed17f702/attachment.html>