[PATCH] D7864: This patch introduces MemorySSA, a virtual SSA form for memory.Details on what it looks like are in MemorySSA.h

[Daniel Berlin via llvm-commits]

On Mon, Feb 1, 2016 at 10:08 PM, George Burgess IV <
george.burgess.iv at gmail.com> wrote:

> > I'm not sure such a flag makes sense, given the above.  I'm not sure
> you *want* to try to alternate between them, because a lot of your order of
> magnitude  speedups will come from doing things fundamentally different
> than random querying (IE move to more "SSA-like" algorithms).
>
> Then, do you know of a better way to allow people to opt-in/opt-out of
> using MemorySSA? Or do you not see the transition to MemorySSA causing many
> issues? (I'm assuming it's the latter. :) )
>

The latter, because it's like saying "should we allow people to opt in/out
of memdep". ;)


> > If you do the optimizations, i'm happy to start to convert passes. I
> was going to just do them in close to the order necessary to preserve
> memssa from beginning to end of opts that use it, but happy to do whatever. Converting
> most passes requires building an update API, and converting a few of them
> and seeing what they want out of updating is the best way i can think of to
> design that API.
>
> WFM * 2. I'll start with the things that we ripped out, then look at
> MemDep to figure out what tricks it has up its sleeve. If there's anywhere
> else you would recommend looking?
>

I would start by taking GVN testcases for invariants, etc, and seeing where
memdep vs memssa give different dependency answers.

(You may want to make a silly memdepprinter if there isn't one)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160201/c5db060d/attachment.html>