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

[Sanjoy Das via llvm-commits]

sanjoy added inline comments.

================
Comment at: docs/LangRef.rst:12147-12148
@@ +12146,4 @@
+continue execution to the end of the physical frame containing them, so all
+calls to ``@llvm.experimental.deoptimize`` must be in "tail
+position":
+
----------------
chandlerc wrote:
> Would it be more precise to say that it must be a 'musttail' call?
At the IR level, semantically, it does "look like" a `musttail` call,
but at the ABI level it is not a `musttail` call from LLVM's
perspective.  Usually the caller frame will have state that is needed
to transition into the deopt continuation, and so it is not okay for
LLVM to lower this call as "pop frame and jump".  This is why I'm
hesitant to specify that calls to experimental.deoptimize have to be
`musttail`.  On the other hand, managed languages typically do have a
guarantee that once we've fully transitioned into the generic /
de-specialized function, the caller frame will have been fully popped;
so it is a lot like a `musttail` call from the "eventual stack growth"
perspective.

A second minor difference is that the restrictions are a little
stricter -- because the intrinsic is polymorphic on the return value,
there is no need to allow the optional `bitcast` (this part is fairly
inconsequential though).

So the summary is that I'm somewhat on the fence on making this a
`musttail` call (or not), and given that changing our mind later would
not involve a lot of interesting code-churn, I'd like to defer that
decision to a later point.  However if either of the points in the
first paragraph strongly resonate with you please let me know.


http://reviews.llvm.org/D17732