[PATCH] D51207: Introduce llvm.experimental.widenable_condition intrinsic

[Artur Pilipenko via Phabricator via llvm-commits]

apilipenko added a comment.

One of the alternatives naming schemes which was discussed is to call this intrinsic `should_deoptimize`. In this case the meaning of the returned value is inverted, so we need to or it with the condition which we want to widen.

    %should_deoptimize = call i1 @llvm.experimental.should_deoptimize()
    %deoptimize = or i1 %cond, %should_deoptimize
    br i1 %deoptimize, label %guarded, label %deopt
  
  guarded:
    ; Guarded instructions
  
  deopt:
    call type @llvm.experimental.deoptimize(<args...>) [ "deopt"(<deopt_args...>) ]

With this phrasing the intrinsic decides whether we want to deoptimize from this method early or not. It's frontend's responsibility to arrange so the `true` returned from `should_deoptimize` would result in a deoptimization with correct state. This is a more limiting phrasing then the proposed `widenable.condition` as it ties the semantics of this intrinsic with deoptimization.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D51207/new/

https://reviews.llvm.org/D51207