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

[Daniel Berlin via llvm-commits]

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.

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. 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).

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> 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
> > wrote:
>
>> On 08/20/2016 12:38 PM, Hal Finkel 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.
>>>
>> 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/54acc713/attachment.html>