<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 11, 2015 at 11:06 AM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</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"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Nov 11, 2015 at 10:41 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"><div class="gmail_extra"><div class="gmail_quote"><span>On Wed, Nov 11, 2015 at 10:32 AM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</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"><div class="gmail_extra"><div class="gmail_quote">I think the idea is to model the intrinsic as a normal external function call: </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">- Can read/write escaped memory</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">- Escapes pointer args</div><div class="gmail_quote">- Functionattrs cannot infer anything about it</div><div class="gmail_quote">- Returns a pointer which may alias any escaped data</div><div class="gmail_quote"><br></div></div></div></blockquote></span><div>As you point out so nicely, there is already a list of stuff that external function calls may do, but we may be able to prove things about them anyway due to attributes, etc.  </div><div><br></div><div>So it's not just an external function call, it's a super-magic one.</div></div></div></div></blockquote><div><br></div></span><div>Right, an external function, with a definition that the compiler will never find.</div><span class=""><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>Now, can we handle that?<br>Sure.</div><div><br></div><div>For example,  i can move external function calls if i can prove things about their dependencies, and the above list is not sufficient to prevent me from moving (or PRE'ing) most of the blackbox calls that just take normal non-pointer args.</div><div>Is that going to be okay?</div><div><br></div><div>(Imagine, for example, LTO modes where i can guarantee i have the entire program, etc.</div><div>You still want blackbox to be magically special in these modes, even though nothing else is).</div></div></div></div></blockquote><div><br></div></span><div>Sure, the compiler can reorder all the memory accesses to non-escaped memory as it sees fit across the barrier. That's part of the normal modelling of external calls.</div><div><br></div><div>I don't know how you could CSE it, though.</div></div></div></div></blockquote><div><br></div><div>You'd have to make sure everything you ever built in LLVM handled this particular intrinsic specially.</div><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> Any call you can't reason about </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> can always use inline asm to talk to external devices or issue a write syscall.</div></div></div></div></blockquote><div><br></div><div>Heck, i could even reason about inline asm if i wanted to ;-).</div><div><br></div><div>My point is that this call is super special compared to all other  calls, and literally everything in LLVM has to understand that.</div><div>The liklihood of subtle bugs being introduced in functionality (IE analysis/etc doing the wrong thing because it is not special cased) seems super high to me.</div><div> <br></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>I don't know how you could practically deploy a super-duper LTO mode that doesn't allow that as part of its model.</div></div></div></div></blockquote><div> </div><div>Sure.</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><br></div><div>The following CFG simplification would be legal, as it also fits the normal model of an external call:</div><div>if (cond) y =llvm.blackbox(x)</div><div>else y = llvm.blackbox(x)</div><div>--></div><div>y = llvm.blackbox(x)</div><div><br></div><div>I don't see how this is special. It just provides an overloaded intrinsic whose definition we promise to never reason about. Other than that it follows the same familiar rules that function calls do.</div></div></div></div>
</blockquote></div><br></div><div class="gmail_extra">You have now removed some conditional evaluation and  jumps.  those  would normally take benchmark time.</div><div class="gmail_extra">Why is that okay?</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>