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

[Philip Reames]

Just for the perspective, how does this compare with our current GVN 
times without Memory SSA?

On 02/25/2015 09:49 AM, Daniel Berlin wrote:
> So, to circle back on timings:
> On my very very large file with lots of functions i use to test GVN 
> timings,
> doing the clobber checks at build time gives:
>
>    3.9350 ( 46.4%)   0.0564 ( 36.2%)   3.9915 ( 46.2%) 4.0004 ( 46.2%) 
>  Global Value Numbering
>    2.4518 ( 28.9%)   0.0276 ( 17.7%)   2.4795 ( 28.7%) 2.4841 ( 28.7%) 
>  Memory SSA
>
>    3.8392 ( 46.2%)   0.0620 ( 37.8%)   3.9012 ( 46.0%) 3.9410 ( 46.1%) 
>  Global Value Numbering
>    2.4047 ( 28.9%)   0.0319 ( 19.4%)   2.4366 ( 28.8%) 2.4532 ( 28.7%) 
>  Memory SSA
>
>    3.9762 ( 46.4%)   0.0699 ( 38.7%)   4.0461 ( 46.3%) 4.1086 ( 46.4%) 
>  Global Value Numbering
>    2.4720 ( 28.9%)   0.0354 ( 19.6%)   2.5074 ( 28.7%) 2.5295 ( 28.6%) 
>  Memory SSA
>
>
> (As a side note, old GVN took 12 seconds, so yay!)
>
> Doing it lazily gives:
>
>   5.4972 ( 60.2%)   0.0795 ( 44.3%)   5.5767 ( 59.9%) 5.6230 ( 60.0%) 
>  Global Value Numbering
>    1.5262 ( 16.7%)   0.0261 ( 14.5%)   1.5523 ( 16.7%) 1.5618 ( 16.7%) 
>  Memory SSA
>
>  5.4386 ( 60.1%)   0.0744 ( 43.1%)   5.5131 ( 59.8%) 5.5430 ( 59.8%) 
>  Global Value Numbering
>    1.5087 ( 16.7%)   0.0251 ( 14.5%)   1.5338 ( 16.6%)   1.5413 ( 
> 16.6%)  Memory SSA
>    5.4627 ( 59.9%)   0.0865 ( 44.3%)   5.5492 ( 59.5%)   5.6065 ( 
> 59.5%)  Global Value Numbering
>    1.5382 ( 16.9%)   0.0296 ( 15.2%)   1.5678 ( 16.8%)   1.5861 ( 
> 16.8%)  Memory SSA
>
>
> So, it definitely makes MemorySSA about 50-60% slower to build.
> However, overall, for GVN, which looks at all loads, it is 
> combined-time 10-15% faster to do it at build time
> (6.2-6.5 seconds vs 6.9-7.0 seconds)
>
> So i think it should at least be an option when building memoryssa 
> (though i admit to not knowing if there is an easy way for passes to 
> give options to analysis passes.  If it keep it a utility, of course, 
> it's easy)
>
>
> Thoughts welcome.
>
>
> To put these pass times in perspective, something simple like 
> dominator tree construction on this file takes:
>    0.6060 (  6.6%)   0.0189 (  9.7%)   0.6249 (  6.7%) 0.6323 (  6.7%) 
>  Dominator Tree Construction
>
> So uh, 1.5 seconds to do memoryssa is not that bad :)
>
>
>
> On Wed, Feb 25, 2015 at 8:44 AM, Daniel Berlin <dberlin at dberlin.org 
> <mailto:dberlin at dberlin.org>> wrote:
>
>
>
>     On Wed, Feb 25, 2015 at 12:07 AM, Sanjoy Das
>     <sanjoy at playingwithpointers.com
>     <mailto: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
>
>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

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