<div dir="ltr">to be 100% concrete, these are what i think you would have to do to move forward sanely with MemDep (MemSSA didn't built the API this way, so it doesn't have these issues), and still provide the existing users what they are using it for.<div><div><br></div><div>1. Either verify that nobody is depending on MDA to give them clobbers for invariant start/end (maybe they are all dead? Things definitely depend on it for lifetime.start/lifetime.end clobbers).</div><div>Assuming some still exist, provide an API that, given a load, tells where starts being invariant/ends being invariant.  Change existing users to use that.</div><div><br></div><div>2. (Optional bonus): Do the same for lifetime markers, which are the other intrinsics here marked the same way.</div><div><br></div><div>3. Handle the issues of hoisting/sinking *the intrinsic calls themselves* somehow, as moving them breaks stuff since you are extending the invariantness range</div><div><br></div><div>4. (Optional bonus) Same for lifetime.start/end </div><div><br></div><div>5. (Bonus points) Think about the issue of hoisting/sinking *operations past them* (IE if you hoist a load above the invariant marker, it's now not invariant).  Not sure what should happen here, if anything.  But it does mean whatever attribute they get marked with may not want to block hoisting past.</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 5, 2016 at 12:48 PM, 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 Fri, Aug 5, 2016 at 12:40 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.co<wbr>m</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Daniel,<span><br>
<br>
Daniel Berlin wrote:<br>
> I really want to say yes, but ....<br>
><br>
> 1. Your argument is identical for the other intrisics right above it.<br>
> None of them touch memory in practice.<br>
> 2. MDA is deliberately returning it as a Dep so that things know where<br>
> the invariants start and end (again, same with lifetime markers).<br>
> I realize this is not ideal (and in fact, sucks), but things depend on it.<br>
><br>
> 3. Without this, you will enable hoisting that is not allowed, if things<br>
> use MDA to perform hoisting.<br>
><br>
> You cannot move the invariant start and end calls, and MDA saying they<br>
> are read-only will enable them to be moved.<br>
<br></span>
Are you saying that they'll get speculated out of control flow?  </blockquote><div><br></div></span><div>Yes, i'm saying the  mechanism currently used to keep them from moving is to say they read/write memory.</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">That<br>
does not seem safe -- how does LLVM know that they won't segfault?<span><br>
</span></blockquote><div><br></div><div><br></div></span><div>I'm not sure i understand.</div><div>These are invariant start and end markers, they generate no real code.</div><div>If you move them, the problem is that the definition of invariant.start says:<br>"<span style="color:rgb(0,0,0);font-family:"Lucida Grande","Lucida Sans Unicode",Geneva,Verdana,sans-serif;font-size:14px">This intrinsic indicates that until an</span><span style="color:rgb(0,0,0);font-family:"Lucida Grande","Lucida Sans Unicode",Geneva,Verdana,sans-serif;font-size:14px"> </span><code style="color:rgb(0,0,0);font-family:Consolas,"Deja Vu Sans Mono","Bitstream Vera Sans Mono",monospace;font-size:0.95em"><span>llvm.invariant.end</span></code><span style="color:rgb(0,0,0);font-family:"Lucida Grande","Lucida Sans Unicode",Geneva,Verdana,sans-serif;font-size:14px"> </span><span style="color:rgb(0,0,0);font-family:"Lucida Grande","Lucida Sans Unicode",Geneva,Verdana,sans-serif;font-size:14px">that uses the return value, the referenced memory location is constant and unchanging.</span></div><div style="color:rgb(0,0,0);font-family:"Lucida Grande","Lucida Sans Unicode",Geneva,Verdana,sans-serif;font-size:14px"></div><div>"</div><div><br></div><div>So if you hoist/sink start or end , you change the bounds of where the memory is unchanging.</div><div><br></div><div>You could fix this, of course, by having the invariant.start and invariant.end calls return pointers, and all things that are invariant use those pointers (or pointers derived from those pointers).  IE express the dependence in SSA directly.</div><div><br></div><div>Then you can move the start/end calls wherever they are valid (IE wherever they are dominated by their operands) and it will not change the semantic effect.</div><div><br></div><div>But that's not the current design.</div><span><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
> We last tried this by saying they did not touch memory (which is<br>
> correct), and peter had to revert the set of changes that gave them "The<br>
> correct answer" because it broke on real code.<br>
<br></span>
Do you happen to remember any relevant revision numbers / zilla bugs<br>
for this?<span><font color="#888888"><br>
<br></font></span></blockquote></span><div>The revert was: "<span style="font-size:inherit;font-weight:inherit">[llvm] r270823 - MemorySSA: Revert r269678 and r268068; replace with special casing in MemorySSA.</span></div><div>"</div><div><br></div><div>This is when we tried this with assume </div><div>Look for emails from pcc around the time you see "[PATCH] D20653: LICM: Do not sink or hoist assume intrinsic calls."</div><div><br>This was a set of followups from peter to try to starting fixing places that tried to hoist them anyway, and it turns out ... it's not a pretty path.</div><div>;)<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><font color="#888888">
-- Sanjoy<br>
</font></span></blockquote></div><br></div></div>
</blockquote></div><br></div></div></div>