[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
llvm-commits at lists.llvm.org
Mon Feb 1 22:17:48 PST 2016
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...
More information about the llvm-commits