<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Feb 18, 2016 at 1:01 PM Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com">sanjoy@playingwithpointers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Feb 18, 2016 at 12:48 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br>
> Heh. I like his more, but I see where you're coming from as well - the easy<br>
> way (for me at least) to look at the guard is as an implicit branch to a<br>
> side exit that restores (or communicates) state back to the interpreter. The<br>
<br>
By "this" do you mean "explicit conditional branch to<br>
bail_to_interpreter"?  That mostly works, except that it does not<br>
allow "widening" type optimizations, as discussed in the very first<br>
email.<br>
<br></blockquote><div><br></div><div>I don't use "this" in my above comment so I'm not sure what you're asking?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> lowering will likely need to surface some amount of that control flow.<br>
> Though I'm not quite sure how you want the intrinsic to perform in the face<br>
> of optimization. What's legal to move across etc. There were some comments<br>
> earlier in the thread, but getting it explicitly laid out in the next<br>
> writeup would be good.<br>
<br>
Yes.  The current status here is that there are some (not specific to<br>
guard intrinsics) issues with the deopt bundles representation that<br>
need to be fixed before we can proceed with implementing guard<br>
intrinsics.<br>
<br></blockquote><div><br></div><div>OK.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> More thoughts:<br>
><br>
> It might make sense for the stackmap intrinsic to go away after this - I<br>
> don't think it's clear though. I'm open to arguments either way.<br>
<br>
We can consider dropping the IR representation of stackmaps, but<br>
that's a separate discussion.  Especially given that they're<br>
intrinsics, I don't think we're paying a high cost in keeping them.<br>
<br></blockquote><div><br></div><div>That's fair. I don't have a strong preference anyhow.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> That said, I didn't see a representation for the deopt bundles? I'm assuming<br>
> they're normal operands to the IR instruction yes?<br>
<br>
Deopt bundles are normal operands to the IR instruction, and they've<br>
been in tree for some time now:<br>
<a href="http://llvm.org/docs/LangRef.html#deoptimization-operand-bundles" rel="noreferrer" target="_blank">http://llvm.org/docs/LangRef.html#deoptimization-operand-bundles</a><br><br></blockquote><div><br></div><div>Ha. That's what I get for popping up so late in your work :)</div><div><br></div><div>-eric </div></div></div>