Sanjoy Das via llvm-dev
2016-Feb-18 21:00 UTC
[llvm-dev] RFC: Add guard intrinsics to LLVM
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. TheBy "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
Eric Christopher via llvm-dev
2016-Feb-18 21:04 UTC
[llvm-dev] RFC: Add guard intrinsics to LLVM
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>
Sanjoy Das via llvm-dev
2016-Feb-18 21:17 UTC
[llvm-dev] RFC: Add guard intrinsics to LLVM
On Feb 18, 2016 1:04 PM, "Eric Christopher" <echristo at gmail.com> wrote:> > > > 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 - theeasy>> > way (for me at least) to look at the guard is as an implicit branch toa>> > side exit that restores (or communicates) state back to theinterpreter. 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?I misread "his" as "this", sorry. -- Sanjoy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160218/c601dae8/attachment.html>