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

[Philip Reames]

On 03/24/2015 05:07 PM, Daniel Berlin wrote:
>
>
> On Tue, Mar 24, 2015 at 4:55 PM, Philip Reames 
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>     This is looking reasonable complete.  Any chance we could land it
>     in it's current form and evolve it in tree?  Tracking changes is
>     becoming quite hard.
>
> Yes, let me add some more comments, update it once more, and declare 
> victory for the moment until someone looks at it again.
>
> The one thing blocking it from being used for say, memcpyoptimizer is 
> that it's not  *quite* lazy enough.
Do you think this would this actually be a performance problem? 
Particularly once we start using this is multiple passes and preserving 
it across them, it's not clear to me how expensive the current form will 
actually be.
>
> I wanted to make it pass in the list of defining blocks, and then it 
> only computes memory ssa on the parents of this block in the dominator 
> tree (since that is all a walk would ever return).
>
> It could be made completely lazy by doing per-variable phi 
> computation, as it hits the last use in a multiple-predecessor block 
>  non-local use, as long as it gets a promise you won't modify the CFG :)
>
> Then we'd just have the walker do something like 
> Def->ensureUseComputed or something to trigger it to do insertion.
>
>
>     Using this to implement a simple cross block DSE might be an
>     interesting proof of concept.  I'm not set on that idea, but it
>     would be nice to have something in tree to show this actually
>     working. 
>
>
> My original goal was to rewrite memcpyoptimizer, rather than write a 
> new pass.
> But i'm happy to do either :)
Either works for me.  I have no strong preference.
> I could also rewrite MergedLoadStoreMotion to use it. It would 
> simplify the code pretty greatly, i think, since it would no longer 
> have to look at/walk successor blocks
>
>     Once we have that, we can migrate other passes to it one by one.
>
>
>     http://reviews.llvm.org/D7864
>
>     EMAIL PREFERENCES
>     http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150324/7c774f09/attachment.html>