[PATCH] D51207: Introduce llvm.experimental.widenable_condition intrinsic
Max Kazantsev via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Sep 6 20:02:19 PDT 2018
mkazantsev added inline comments.
================
Comment at: docs/LangRef.rst:15097-15099
+defined as follows: as long as the block `deopt` only contains the
+call to ``@llvm.experimental.deoptimize`` and instructions without
+side effects, it is valid to replace
----------------
apilipenko wrote:
> Why do you need this limitation?
As stated above, we want these two constructions do exactly the same thing:
; Unguarded instructions
call void @llvm.experimental.guard(i1 %cond, <args...>) ["deopt"(<deopt_args...>)]
; Guarded instructions
and
block:
; Unguarded instructions
%widenable_condition = call i1 @llvm.experimental.widenable.condition()
%new_condition = and i1 %cond, %widenable_condition
br i1 %new_condition, label %guarded, label %deopt
guarded:
; Guarded instructions
deopt:
call type @llvm.experimental.deoptimize(<args...>) [ "deopt"(<deopt_args...>) ]
If there is something side-effecting before deoptimization in `deopt` block, these two constructions are obviously not equivalent.
https://reviews.llvm.org/D51207
More information about the llvm-commits
mailing list