<p dir="ltr">TIL. That makes sense then -- thanks. </p>
<div class="gmail_quote">On Mar 10, 2016 7:18 PM, "Daniel Berlin" <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>> wrote:<br type="attribution"><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">On Thu, Mar 10, 2016 at 7:16 PM, George Burgess IV <span dir="ltr"><<a href="mailto:george.burgess.iv@gmail.com" target="_blank">george.burgess.iv@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">george.burgess.iv added inline comments.<br>
<span><br>
================<br>
Comment at: lib/Transforms/Utils/MemorySSA.cpp:970<br>
@@ +969,3 @@<br>
+      // a valid construct, we still need to handle it, because users can ask<br>
+      // the walker to walk arbitrary IR.<br>
+      ModifyingAccess = FirstDef ? FirstDef : MSSA->getLiveOnEntryDef();<br>
----------------<br>
</span><span>dberlin wrote:<br>
> Errr.<br>
> What?<br>
><br>
> A. In buildMemorySSA, we already detect forward-unreachable-from-entry blocks and mark all definitions as live on entry. So they should never loop anywhere in the case you are listing, because if the loop has no entry, all the defs/uses in it should be to live on entry.<br>
><br>
> So i don't see how this can happen.<br>
><br>
> However<br>
> B.<br>
> Because we already handle forward unreachable-from-entry blocks and mark all defs in them as liveonentry in buildmemoryssa,  is there a good reason we shouldn't just detect reverse unreachable-from-entry blocks and do the same?<br>
><br>
> We can say that MemorySSA has no forward or reverse unreachable blocks, and make the IR sane in them. This is because we have no real IR, and so, at worst, we can do what we do now:<br>
><br>
> Mark anything in unreachable as live on entry, and remove all phis in unreachable.  We could go one more, and remove all the memory accesses entirely if we wanted to.<br>
><br>
><br>
> A. In buildMemorySSA, we already detect forward-unreachable-from-entry blocks and mark all definitions as live on entry. So they should never loop anywhere in the case you are listing, because if the loop has no entry, all the defs/uses in it should be to live on entry.<br>
<br>
</span>Correct.<br>
<span><br>
> So i don't see how this can happen.<br>
<br>
</span>I was thinking that the update API might be able to get us in this situation, but after looking at it, I think I was wrong. :)<br>
<br>
Ternary replaced with `assert(FirstDef);`<br>
<span><br>
> Because we already handle forward unreachable-from-entry blocks and mark all defs in them as liveonentry in buildmemoryssa, is there a good reason we shouldn't just detect reverse unreachable-from-entry blocks and do the same?<br>
<br>
</span>I can't think of one. Though, I'm also not sure I understand backwards reachability,<br>
<span><br></span></blockquote><div>It's possible for blocks to go nowhere.</div><div><br>There is no guarantee they ever reach an exit :)</div><div><br></div><div><br></div></div></div></div>
</blockquote></div>