[PATCH] D19821: [EarlyCSE] Port to use MemorySSA (disabled by default). NFC.

[Daniel Berlin via llvm-commits]

So, i would like to see real numbers that say this is going to slow down
anything (or speed it up).
As I said, if the objection is speed, yes, we should look into that, and if
something needs to be done, we should do it.

We can amortize the cost quite well. It should essentially cost nearly
nothing past initial setup cost (it's not harder than the SSA updates we do
today, which are not expensive).

The entire plan is actually to amortize the cost.
Right now, the default pass schedules put things that use memdep mostly in
a row.

At the outset, with a little work, we should have to compute memoryssa
twice (once before MLSM/GVN/MemCpyOpt, once before DSE).
Getting all the way to DSE is harder in the sense that it's a longer way to
go to preserve passes.

But it's also interesting to note that none of these passes preserve memdep
today, and the cost of doing memdep queries on every store (as DSE would)
with no cache, should be more than the cost of memoryssa building + usage.

It definitely can be made to be so.
So that part doesn't worry me.

Shoving this in EarlyCSE, if it's fast enough, seems reasonable at a
glance.  In a perfect world, it would be good to preserve it everywhere.
I'm not sure, at the beginning, it makes sense to try to preserve it across
tons and tons of passes that won't ever use it, but do touch memory
heavily.  So i would expect EarlyCSE to end up as another computation point
for quite a while.

That needs to be traded off past how much better/easier/etc it makes
EarlyCSE.



On Fri, May 27, 2016 at 1:56 PM, Geoff Berry <gberry at codeaurora.org> wrote:

> gberry added a comment.
>
> @reames @dberlin Regarding the compile time impact, do you think it would
> be worth pursuing a change to make EarlyCSE's use of MemorySSA optional?
> That way we could avoid using it for early passes EarlyCSE and only use it
> for later ones, perhaps even influenced by optimization level?  A related
> aspect of the plan for MemorySSA that I'd like to understand is how well we
> think we'll be able to amortize the cost of building it by
> preserving/maintaining it across passes.  Daniel, can you share your
> thoughts on that?
>
>
> http://reviews.llvm.org/D19821
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160527/f29422c5/attachment.html>