[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:25 PM, Philip Reames <listmail at philipreames.com>
wrote:

> The quoting got screwed up in my email client.  Hopefully I'm responding
> to the right bits here...
>
> On 08/20/2016 01:07 PM, Daniel Berlin wrote:
>
> Besides that, i guess i don't understand this argument:
> "Having a threshold where our ability to optimize falls off a cliff just
> seems really undesirable"
>
> This is *already* true in literally every single pass using memdep today,
> which is most of the memory optimization passes.
> It simply *gives* up, and returns "unknown clobber" in a *large variety of
> cases* due to a large variety of limits.
>
> For example: if you have 100 instructions in a block, it won't go past
> that block, it will stop.
>
> Yep, absolutely.  And that's a problem.  It's a problem that MemorySSA
> will help address, but it is a problem today.
>
> In a world where we are not moving to MemorySSA in the near future (which
> from your other post sounds like a world we are not actually in), thinking
> hard about how to avoid adding another limit would be worthwhile.
>
...

You're essentially making a slipper slope argument here.  One I disagree
> with.  Just because we've been forced to compromise in one particular way
> in one spot does not imply that we should compromise in that same way in
> all places.


I don't disagree with your methodology, only your data :)

i would agree with you if it was the case that we had 2-3 out of 20 passes
that had these kinds of limits, and were trying to decide what to do about
the 4th. That's a slippery slope, because you don't want to end up at 20 by
sliding down the slope.
Here, it's really 19 out of 20 passes, and we're trying to decide what to
do about the 20th.  That's not a slippery slope. You already fell down the
slope, for better or for worse.  Doing it in the 20th place pretty much
doesn't matter IMHO, unless we have a reason to believe it's materially
harder to undo it than the other 19.

Put another way, we already compromised the same way in all but one place,
and it adds up to a lot of places. At that point, it doesn't make a lot of
sense to me to say we shouldn't compromise in the last one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160820/99b0dd5c/attachment.html>