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

[Philip Reames via llvm-commits]

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.
>
> So does BasicAA for that matter, with it's various depth limits.
>
> This simply drops our ability to optimize off a cliff *already*, so we 
> are already down that road.
>
> If you run GVN
>
> "load a
> 98 non-conflicting stores
> load a"
>
> it will optimize it
>
> and
>
> "load a
> 99 non-conflicting stores
> load a"
> it will do nothing
> etc
>
> We are *already down that road*.  Whether we fix LICM or not is almost 
> immaterial, as *nothing else* will do optimization.
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.
> We already know we can't fix the main thing sanely (if you partition 
> in memdep, and associate virtual memory accesses with each thing 
> representing the partitions, congrats, you've basically invented 
> memoryssa).
I think this is the key part of your answer.  You're basically saying 
"yes, we thought about other options in great depth; all the good ones 
basically reduce to using or reimplementing MemorySSA". That's a 
perfectly reasonable answer to my question.

> MemorySSA is the thing walking us back up the road.
>
>
>
>
> On Sat, Aug 20, 2016 at 12:56 PM, Daniel Berlin <dberlin at dberlin.org 
> <mailto:dberlin at dberlin.org>> 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.
>
>     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 <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/92a115ba/attachment.html>