[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