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

[Daniel Berlin]

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> wrote:

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