[llvm-dev] RFC: Add guard intrinsics to LLVM
Eric Christopher via llvm-dev
llvm-dev at lists.llvm.org
Thu Feb 18 13:04:14 PST 2016
On Thu, Feb 18, 2016 at 1:01 PM Sanjoy Das <sanjoy at playingwithpointers.com>
> On Thu, Feb 18, 2016 at 12:48 PM, Eric Christopher <echristo at gmail.com>
> > Heh. I like his more, but I see where you're coming from as well - the
> > 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.
> 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
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
> > of optimization. What's legal to move across etc. There were some
> > 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
> > 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
> > 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:
Ha. That's what I get for popping up so late in your work :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev