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

Daniel Berlin dberlin at dberlin.org
Tue Feb 24 19:06:21 PST 2015


On Tue, Feb 24, 2015 at 6:14 PM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> > We don't treat it specially, we actually do exactly what you say.
> > We could just pick any argument and end up with the same results. We just
> > happen to figure it's most likely to find the version closest to the top
> of
> > the function, which is most likely to be the highest (in the dominator
> tree)
> > version we are trying to reach.
> > Otherwise,  we always check to make sure the version of all arguments
> agree.
>
> Thanks, this makes sense now.
>

I'll update it to make this more clear, and i will also just make it pick
first argument and see if it really matters in timings.



>
> A related question:  is it correct (and profitable) to do this:
> MU->setUseOperand(getClobberingMemoryAccess(MU->getMemoryInst())?
>

So, there is technically no guarantee that you will get an access that
dominates you.
Otherwise, I can't honestly think of a reason you can't do this assuming
you get to a def that does dominates you.

It's what value numbering is doing anyway.




> Does it make sense for the MemorySSA pass to apply this transform to a
> fixed point, especially at higher optimization levels?
>

This is a harder question.  If you do it to every use, you may end up
spending a bunch of time doing that.
You are essentially trading build time for query  time.
If the optimization pass only asks about certain loads, it may not be a
good tradeoff.

GVN happens to look at every load anyway, so it may be good to do for GVN.

Let me run some before/after numbers.




>
> -- Sanjoy
>
> >
> > There is one caveat here: We have to skip cyclic phi node arguments (IE
> > arguments that lead us back to this phi node). So we can't pick one of
> those
> > to be the argument to check against :)
>
> >
> >
> >
> >
> >> It's
> >> 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/20150224/a0bd487e/attachment.html>


More information about the llvm-commits mailing list