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

[Philip Reames via llvm-commits]

reames added a comment.

It looks like this is missing codegen support.  For now, I'd suggest lowering to call to a known symbol.  __llvm_deoptimize?


================
Comment at: docs/LangRef.rst:12107
@@ -12104,1 +12106,3 @@
 
+'``llvm.experimental.deoptimize``' Intrinsic
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
----------------
Naming wise, I liked the term side exit much better.

================
Comment at: docs/LangRef.rst:12115
@@ +12114,3 @@
+
+      declare type @llvm.experimental.deoptimize()
+
----------------
Might be better to declare this as taking unspecified arguments which are interpreted by the runtime.

================
Comment at: docs/LangRef.rst:12124
@@ +12123,3 @@
+version of a function into another (typically more generic, hence
+slower) version.
+
----------------
As written, this explanation is too generic.  The intrinsic specifically only allows transfer of control in one direction - leaving the current code.  It does not allow entries.  Having a separate intrinsic which modelled OSR entry points might some day be useful, but that's a different problem.

================
Comment at: docs/LangRef.rst:12126
@@ +12125,3 @@
+
+In languages with a fully integrated managed runtime like Java this
+intrinsic can be used to implement "uncommon trap" like functionality.
----------------
Java, or JavaScript

================
Comment at: docs/LangRef.rst:12127
@@ +12126,3 @@
+In languages with a fully integrated managed runtime like Java this
+intrinsic can be used to implement "uncommon trap" like functionality.
+In unmanaged languages like C and C++, this intrinsic can be used to
----------------
or "side exit"

================
Comment at: docs/LangRef.rst:12143
@@ +12142,3 @@
+operand bundle <deopt_opbundles>`) and returns the value returned by
+the deoptimization continuation.
+
----------------
Might be good to say something about the interpretation of deopt continuation as being explicitly out of scope for LLVM.  (i.e. go invoke random code which must...)

================
Comment at: lib/Transforms/Utils/InlineFunction.cpp:1806
@@ -1801,1 +1805,3 @@
 
+  if (InlinedDeoptimizeCalls) {
+    Function *NewDeoptIntrinsic = nullptr;
----------------
Can't you just skip the entire region if the return type of the caller is the same as the callee?  Actually, no, you need to remove them from the normal returns so that we early terminate the parent as well.  Can you restructure/add comments to make both parts clear?


http://reviews.llvm.org/D17732