[llvm-dev] RFC: Add guard intrinsics to LLVM

[Sanjoy Das via llvm-dev]

On Thu, Feb 18, 2016 at 12:48 PM, Eric Christopher <echristo at gmail.com> wrote:
> Heh. I like his more, but I see where you're coming from as well - the easy
> way (for me at least) to look at the guard is as an implicit branch to a
> side exit that restores (or communicates) state back to the interpreter. The

By "this" do you mean "explicit conditional branch to
bail_to_interpreter"?  That mostly works, except that it does not
allow "widening" type optimizations, as discussed in the very first
email.

> lowering will likely need to surface some amount of that control flow.
> Though I'm not quite sure how you want the intrinsic to perform in the face
> of optimization. What's legal to move across etc. There were some comments
> earlier in the thread, but getting it explicitly laid out in the next
> writeup would be good.

Yes.  The current status here is that there are some (not specific to
guard intrinsics) issues with the deopt bundles representation that
need to be fixed before we can proceed with implementing guard
intrinsics.

> More thoughts:
>
> It might make sense for the stackmap intrinsic to go away after this - I
> don't think it's clear though. I'm open to arguments either way.

We can consider dropping the IR representation of stackmaps, but
that's a separate discussion.  Especially given that they're
intrinsics, I don't think we're paying a high cost in keeping them.

> That said, I didn't see a representation for the deopt bundles? I'm assuming
> they're normal operands to the IR instruction yes?

Deopt bundles are normal operands to the IR instruction, and they've
been in tree for some time now:
http://llvm.org/docs/LangRef.html#deoptimization-operand-bundles

-- Sanjoy