[PATCH] D17732: Introduce @llvm.experimental.deoptimize

Philip Reames via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 9 14:57:44 PST 2016


reames added a comment.

Sanjoy and I talked about this offline; let me summarize what we talked about.

I expressed discomfort with reusing RS4GC as Sanjoy suggested.  While this would seem to be the path of least resistance, it seemed odd to me to tie deopt and GC so closely coupled together.  We clearly need to reuse the backend representation (i.e. the STATEPOINT pseudo op) since we need the stack lowering and stack map entry pieces, but reusing the IR rewriting/lowering code seemed overly coupled.

After discussion, we settled on the following approach.  Sanjoy is going to examine whether we could reuse the StatepointLowering.cpp code directly from SelectionDAGBuilder's intrinsic lowering code.  This would imply that we don't need to wrap a call to @llvm.experimental.deoptimize in an statepoint to get it lowered to a STATEPOINT psuedo op.  It also gives us the building block for a possible future change which removes the deopt arguments from the statepoint intrinsic entirely in favour of a deopt bundle attached to the call to the statepoint.

(Worth noting, we could have used a PATCHPOINT psuedo op and not a STATEPOINT one for the lowering of the deoptimize call.  The difference is live-on-call/in-regs vs live-through-call/on-stack semantics for the deopt arguments.  We decided to use the STATEPOINT pseudo op mostly because that's what we have more experience with.  We may revisit this lowering detail in the future, but it wasn't worth the churn right now.)

p.s. I'm deferring to Sanjoy on whether he wants to do everything within this patch or separate the lowering into it's own patch.  He'll make that decision and potentially land this patch without the lowering code or argument handling.  I've already given an LGTM for that part and that still stands.


http://reviews.llvm.org/D17732





More information about the llvm-commits mailing list