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

[Eric Christopher via llvm-dev]

On Thu, Feb 18, 2016 at 1:01 PM Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> 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.
>
>
I don't use "this" in my above comment so I'm not sure what you're asking?


> > 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.
>
>
OK.


> > 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's fair. I don't have a strong preference anyhow.


> > 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
>
>
Ha. That's what I get for popping up so late in your work :)

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160218/cc8a0043/attachment-0001.html>