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

[Artur Pilipenko via Phabricator via llvm-commits]

apilipenko 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
----------------
mkazantsev wrote:
> 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.
> 
Sorry, I don't quite follow you. *These two* constructions are exactly the same. widenable condition representation just enables more flexibility and you can have some extra code before deoptimization. So with widenable condition representation you can express more than what you could do with old guards.

I don't think that there are correctness or profitability reasons to impose this limitation.


https://reviews.llvm.org/D51207