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

[Daniel Berlin]

On Tue, Mar 24, 2015 at 5:28 PM, Philip Reames <listmail at philipreames.com>
wrote:

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

If it's preserved, probably not.
Something is going to pay the cost of looking at all the blocks. Right now,
memcpyoptimizer does *not* look at all loads, but it looks at all stores
and calls.

If we assume that is most blocks, the cost will not increase.
:)

Eventually, you end up looking at all blocks, and if you get to GVN, it
looks at *all* stores and loads in the program, so at that point, there is
no additional cost.

So we may take a temporary hit.

The algorithms  to update it in the presence of CFG changes are identical
to our current SSA update algorithms, they just need to be done (and an API
to inform memoryssa that you removed something is needed)



>  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/a3523b2d/attachment.html>