[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
Wed Feb 25 08:44:39 PST 2015


On Wed, Feb 25, 2015 at 12:07 AM, Sanjoy Das <sanjoy at playingwithpointers.com
> wrote:

> > So, there is technically no guarantee that you will get an access that
> > dominates you.
>
> I'm unable to come up with a situation where we'd start off with
> memory-def dominating memory-uses and getMemoryClobberingAccess (as it
> is implemented currently) would return a non-dominating memory access.
> Do you have an example where this would happen?
>

As currently implemented, you are correct, it will not.
But I have not finished integration into GVN yet.

Currently, GVN *wants* to know the clobber in all cases so it can see if it
can pull the store value out if possible.

So i am likely to  have to change it (or build a new API) to track and give
the clobber if it's a branch above a phi node.

I can certainly build a new API for this, or i could just make doing what
you suggest something it does internally while building.

But otherwise, my main use case is GVN, and i'm a bit wary of building an
API for the rest (because i have no idea what others want :P)


> > 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.
>
> Makes sense, thanks!
>
> A related question is if LLVM should cache the result of
> `getClobberingMemoryAccess` in the MemoryAccess it computed the result
> for (and the other MemoryAccess' it had to look at, transitively).
> That seems like a good idea irrespective of how many memory ops were
> queried.
>

 Yes, i think doing this makes sense, it'll save densemap lookups.


> -- Sanjoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150225/503bcc25/attachment.html>


More information about the llvm-commits mailing list