<div dir="ltr">Also, as a natural followup, i'll pointed out  that GCC experimented with must/may defs (IE we have MemoryMustDef to represent strong updates, and MemoryMayDef to everything else), as well as a separate MemoryKill (for inline assembly we didn't understand or instructions that were "clobbers of all memory").<div><br><div><div>It also allowed for multiple "heap versions" to be live at once (To try to reduce the length of the chains).</div><div>This required multiple memorydefs/uses on a single instruction, as well as multiple phis<br><div><br></div><div>In practice, nothing used any of these distinctions to any good effect.</div><div>In the end, they all just wanted to walk the chains, and having multiple heap versions means walking more chains (even if some are shorter), so in the end it did not end up making the compiler faster, but it did make it more complicated :)</div><div><br></div><div>After roughly 10-12 years (i forget how long it's been) of playing with different options, GCC is also  now back to just MemoryDef and MemoryUse, and a single heap version.</div><div><br></div><div><br></div><div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 11:32 AM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Feb 25, 2015 at 11:31 AM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Feb 25, 2015 at 11:05 AM, James Molloy <span dir="ltr"><<a href="mailto:james.molloy@arm.com" target="_blank">james.molloy@arm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Daniel,<br>
<br>
One inline comment about the design. Sorry for the naiveity.<br>
<br>
Cheers,<br>
<br>
James<br>
<br>
<br>
================<br>
Comment at: include/llvm/Transforms/Utils/MemorySSA.h:150<br>
@@ +149,3 @@<br>
+// All defs also have a use<br>
+class MemoryDef : public MemoryUse {<br>
+public:<br>
----------------<br>
I don't understand this: Firstly, why must all defs have a use?</blockquote><div><br></div></span><div>So let me first give the theoretical answer:</div><div><br></div><div>MemorySSA is, abstractly about heap versions.</div><div>Every store generates a new heap version.</div><div>Every use is associated with a give heap version</div><div>In order to be able to know what the heap version was prior to a given store, the def is also a use.</div><div> <br></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>It is intended</div></div></div></div></blockquote></span><div>         ^ not </div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>to perfectly represent the semantics of the actual memory operations, but give a way to have factored use-def chains over memory operations that you can disambiguate without needing to walk back through all instructions in the CFG to find clobbers.</div><div><br></div><div><br></div><div>Practically:</div><div><br></div><div>Because you need some way to link def-def, or else you have nowhere to walk if the current store is a "false def" for a given load.</div><div><br></div><div>IE given</div><div><br></div><div>store @a, %c</div><div>store @b, %d</div><div>load @a</div><div><br></div><div>MemorySSA for this will be:<br><br></div><div>; 1 = MemoryDef(0)</div><div>store @a, %c</div><div>;2 = MemoryDef(1)</div><div>store @b, %d</div><div>;MemoryUse(2)</div><div>%e = load @a</div><div> <br></div><div>When you walk from the load at %e, you  get to the store at  2= MemoryDef(1), say "does this really alias my load", get "no", and want to keep going.  You can do this, because there is a def-def chain, so you go from 2 = MemoryDef(1) to 1 = MemoryDef(0), ask the same question, get "yes", and stop.</div><div><br></div><div>If def's did not have uses, it would look like this instead:<br><br></div><div><div>; 1 = MemoryDef()</div><div>store @a, %c</div><div>;2 = MemoryDef()</div><div>store @b, %d</div><div>;MemoryUse(2)</div><div>%e = load @a</div><div> <br></div></div><div><br></div><div>Now you do the same walk.</div><div>You get to the store at 2 = MemoryDef(), query whether it is a real alias, get "no", and you are stuck, because you have no chain that leads back to the next store :)</div><span><div><br></div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> We can store without loading the resulting value back.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Secondly, you've used inheritance which is an "is-a" relationship. Is there something fundamental I'm missing here?<br></blockquote><div><br></div><div><br></div></span><div>All memorydefs are in fact, memoryuses as well.</div><div><br></div></div></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>