Introduce llvm.experimental.widenable_condition intrinsic

[mkazantsev]

Summary

This patch introduces a new instinsic @llvm.experimental.widenable_condition
that allows explicit representation for guards. It is an alternative to using
@llvm.experimental.guard intrinsic that does not contain implicit control flow.

We keep finding places where @llvm.experimental.guard is not supported or
treated too conservatively, and there are 2 reasons to that:

• @llvm.experimental.guard has memory write side effect to model implicit control flow, and this sometimes confuses passes and analyzes that work with memory;
• Not all passes and analysis are aware of the semantics of guards. These passes treat them as regular throwing call and have no idea that the condition of guard may be used to prove something. One well-known place which had caused us troubles in the past is explicit loop iteration count calculation in SCEV. Another example is new loop unswitching which is not aware of guards. Whenever a new pass appears, we potentially have this problem there.

Rather than go and fix all these places (and commit to keep track of them and add support
in future), it seems more reasonable to leverage the existing optimizer's logic as much as possible.
The only significant difference between guards and regular explicit branches is that guard's condition
can be widened. It means that a guard contains (explicitly or implicitly) a deopt block successor,
and it is always legal to go there no matter what the guard condition is. The other successor is
a guarded block, and it is only legal to go there if the condition is true.

This patch introduces a new explicit form of guards alternative to @llvm.experimental.guard
intrinsic. Now a widenable guard can be represented in the CFG explicitly like this:

  %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...>) ]

The new intrinsic @llvm.experimental.widenable.condition has semantics of an
undef, but the intrinsic prevents the optimizer from folding it early. This form
should exploit all optimization boons provided to br instuction, and it still can be
widened by replacing the result of @llvm.experimental.widenable.condition()
with and with any arbitrary boolean value (as long as the branch that is taken when
it is false has a deopt and has no side-effects).

For more motivation, please check llvm-dev discussion "[llvm-dev] Giving up using
implicit control flow in guards".

This patch introduces this new intrinsic with respective LangRef changes and a pass
that converts old-style guards (expressed as intrinsics) into the new form.

[sanjoy]

Conceptually this seems fine to me, but I won't have time to do a proper review.

[fedor.sergeev]

The code looks fine.
I see that all your tests have empty deopt bundles.
Wouldnt it make sense to add something there, just in case?

include/llvm/IR/Intrinsics.td

833 ↗

(On Diff #162330)

for guards represented as explicit branches

include/llvm/Transforms/Scalar/ExplicifyGuards.h

1 ↗

(On Diff #162330)

"intinrics" -> intrinsics

[mkazantsev]

Fixed comments, added bundles to tests.

[fedor.sergeev]

Thanks for test update.
LGTM (with new pm nit as noted).

lib/Transforms/Scalar/ExplicifyGuards.cpp

119 ↗

(On Diff #163759)

PreservedAnalyses::all() ?

[mkazantsev]

lib/Transforms/Scalar/ExplicifyGuards.cpp

119 ↗

(On Diff #163759)

Eh, yes. Thanks for pointing out!

[mkazantsev]

Fixed analysis preservation.

[apilipenko]

docs/LangRef.rst

15097–15099 ↗

(On Diff #163770)

Why do you need this limitation?

[reames]

Overall, looks pretty good. One rounds of comments, but I'm expecting this to converge quickly.

I think there's a missing piece here. How do widennable_conditions themselves get lowered? I think that belongs to be in this patch so that it's a whole contained, end to end piece.

A reasonable choice would be to say that CGP or SelectionDAG just lowers them directly to the constant false.

docs/LangRef.rst

15109 ↗

(On Diff #163770)

The text here needs tweaked. I'd suggest:
%widenable_cond_orig = call i1 @llvm.experimental.widenable.condition()
%widenable_cond = and i1 %widenable_cond_orig, %any_other_cond

15119 ↗

(On Diff #163770)

You're wording here is problematic. As written, it's only legal to lower *if* the else leads to a deopt block which I'm pretty sure is not what you meant. I think you can just drop everything after "either true or false."

15125 ↗

(On Diff #163770)

This doesn't sound like part of lowering.

Why don't you move this to semantics and reword it as:
"wcond" will never throw an exception and thus cannot be invoked.

include/llvm/Transforms/Scalar/ExplicifyGuards.h

1 ↗

(On Diff #163770)

I'm not actively objecting to the structure here, but this really just feels like another form of guard lowering. Maybe if would be better to reuse the existing implementation and just have a parameter to control which form we're lowing to? LowerGuards vs LowerGuardsToWidennableConds?

lib/Transforms/Scalar/ExplicifyGuards.cpp

80 ↗

(On Diff #163770)

"explicify" as a verb feels very awkward. "MakeGuardsExplicit" would be more clear.

[mkazantsev]

docs/LangRef.rst

15097–15099 ↗

(On Diff #163770)

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.

[mkazantsev]

include/llvm/Transforms/Scalar/ExplicifyGuards.h

1 ↗

(On Diff #163770)

I had another model in my head. This pass will make guards explicit, but these explicit guards are still guards (i.e. they can be widened). LowerGuards's comments states:

// This pass lowers the llvm.experimental.guard intrinsic to a conditional call
// to @llvm.experimental.deoptimize.  Once this happens, the guard can no longer
// be widened.

I don't want the semantics of LowerGuards be changed. My plan was to teach it to turn widenable_condition calls to true, so that we preserve the invariant "no widening is possible after LowerGuards".

[mkazantsev]

Fixed LangRef, renamed pass to "MakeGuardsExplicit".

[apilipenko]

docs/LangRef.rst

15097–15099 ↗

(On Diff #163770)

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.

[reames]

LGTM.

I'm approving this in the current form, despite a bit of hesitation doing so. I'd like to see the conversation around the restriction of widening based on target block to continue. I think there's a good change we'll want to tweak the semantics there, but I see that as a minor tweak, not a major redesign.

There are a couple of follow ups I'd like to see here.

1. A default lowering strategy for the new representation. (Likely in SelectionDAG).
2. (Optional) Extending the existing LowerGuard pass to lower the new form as well.
3. Tests for EarlyCSE, InstCombine, GVN, and DSE which show that two adjacent calls to the widen intrinsic aren't merged and that memory can be forwarded past. (Note: The first part is profitability, but the second is legality.)

lib/Transforms/Scalar/MakeGuardsExplicit.cpp

72 ↗

(On Diff #164381)

I don't think this needs to use the guard calling convention. It'll never get lowered. The important bit was using this CC on the deopt call which will.

[sanjoy]

docs/LangRef.rst

15097–15099 ↗

(On Diff #163770)

I agree with Artur here; @llvm.experimental.widenable.condition is technically an independent concept from @llvm.experimental.deoptimize though of course it is heavily inspired by it.

For instance with @llvm.experimental.widenable.condition you could do things like:

int f(int x) {
  if (@llvm.experimental.widenable.condition()) {
    return faster_to_execute(x);
  } else {
    return easier_to_constant_fold(x);
  }
}

and later fold @llvm.experimental.widenable.condition() to false or true depending on whether f was inlined into a call site where x is a compile time constant or not.

We should also not spec @llvm.experimental.widenable.condition() as returning undef since undef is problematic. Instead we should say each call of @llvm.experimental.widenable.condition() non-deterministically returns true or false but the returned value is a normal i1 and does not have magic properties like undef.

[mkazantsev]

I tried to reformulate the semantics to make it independent on deoptimize intrinsic.

[mkazantsev]

Made changes to LangRef to make the widening part independent on deoptimize intrinsic. After giving it some thought, I see no solid reason why we should impose any limitations on deopt block.

[mkazantsev]

I would ask one more round of review for changes made to LangRef. I tried to make it more generic and less reliant on deopt's specifics than it used to be.

[fedor.sergeev]

docs/LangRef.rst

15058 ↗

(On Diff #165713)

Plural form looks weird here. Single intrinsic represents a single condition...

15152 ↗

(On Diff #165713)

without showing a use of %new_cond this additional instruction does not really change anything.
Since you show the same transform with %new_cond usage below I believe two code-blocks shown above can be deleted without sacrificing anything.

[sanjoy]

docs/LangRef.rst

15085 ↗

(On Diff #165897)

I think this spec should just be "The intrinsic `@llvm.experimental.widenable.condition() always non-deterministically returns true` or false." The ", and it is guaranteed that any returned value leads to correct program execution and creates no undefined behavior in code" bit is true of everything in LLVM IR -- the frontend has to ensure the IR it generated is correct and doesn't have UB.

I'd also emphasize that every invocation of this intrinsic produces a single well defined value non-deterministically (so it isn't like undef).

15146 ↗

(On Diff #165897)

Drop the "always".

15161 ↗

(On Diff #165897)

Not sure if this belongs in the langref, but the intrinsic must be RAUW'ed with the stronger condition, replacing just one use is unsound right?

15174 ↗

(On Diff #165897)

This is an important detail; not from a semantics perspective but from a performance perspective. I'm wondering if this behavior should be a part of name of the intrinsic (or maybe even that the intrinsic should have an argument which is what we default lower the intrinsic to).

For instance, given this spec it would be correct but unwise to lower a range check to:

%w = widenable_cond();
if (%w || out_of_bounds()) deoptimize();

but there is nothing in its name that makes this obvious.

[mkazantsev]

docs/LangRef.rst

15161 ↗

(On Diff #165897)

I see no problem in replacing only one use. It maybe makes no sense, but by definition it should be no bug.

15174 ↗

(On Diff #165897)

I think that the last sentence about the default lowering strategy implies this, but actually it is OK to implement a different lowering strategy if at some use case this one is non-profitable.

[mkazantsev]

Addressed comments to LangRef.

[sanjoy]

docs/LangRef.rst

15161 ↗

(On Diff #165897)

What happens if the initial program is:

%c = widenable_cond();
%x = xor %c, %c

In this original program %x is always false, but if you replace one use of %c with a different value than the other use then %x may not be false.

[mkazantsev]

docs/LangRef.rst

15161 ↗

(On Diff #165897)

We should preserve the invariant that the program is correct whether %c is true or false; even in your example we should guarantee that any value of %x that can be produced this way still leads to correct program execution. But I agree that there can be something fishy there; I'll make this correction.

[mkazantsev]

Added clarification about RAUW to Lowering section.

[mkazantsev]

Can we go with this version? :)

[chandlerc]

docs/LangRef.rst

15134–15137 ↗

(On Diff #169947)

I really like this proposal, but the term "widenable condition" really doesn't help me understand it at all.

Have you all thought of other terminology that might work here?

Some ideas:

"equivalent condition"
"equivalent alternative condition"

Something focusing on the fact that this intrinsic models a value which can inhabit two alternative states that are semantically equivalent when executed.

Thoughts?

15145–15148 ↗

(On Diff #169947)

I would phrase this the other way around. I think the important thing to mention about undef here is its *difference*. I also wouldn't focus first on the *use case*, but the *semantic* difference:

While this may appear similar in semantics to `undef`, it is very different in that an invocation produces a particular, singular value. It is also intended to be lowered late, and remain available for specific optimizations and transforms that can benefit from its special properties.

15085 ↗

(On Diff #165897)

I don't think "always" adds much value here.

I also think "non-deterministically" can be confusing to the reader as this doesn't cause the *compiler* to fold them non-deterministically.

I wonder if we could phrase the semantics more like:

The intrinsic ``...`` returns either `true` or `false`. For each evaluation of a call to this intrinsic, the program must be valid and correct both if it returns `true` and if it returns `false`. This allows transformation passes to replace evaluations of this intrinsic with either value whenever one is beneficial.

Uncertain how others feel about this approach to the semantics.

15174 ↗

(On Diff #165897)

I don't think we need to allow passing in the directionality... FEs can choose to emit the alternatives in the structure necessary?

But I do like the point that maybe the fact that one is the "default" should be evident to the FE author so that they can choose the structure correctly.

[mkazantsev]

docs/LangRef.rst

15134–15137 ↗

(On Diff #169947)

This name was chosen specifically because it is supposed to be used for widening transforms. Actually the semantics that is given in LangRef is wider and has more possible applications than what I was thinking of. :)

I am open to discussion how it can be called, but how about this: we merge it as is and then continue this discussion separately. I don't really like "equivalent condition" (without context, it's unclear equivalent to what?), but I agree that we can change the name. Just let's discuss it separately and merge it as pure NFC when we settle to some option so that I could be unblocked on items where this can be used.

[mkazantsev]

Addressed comments, LangRef fixed. As for naming question, I am open to discussion, but I'd prefer to have it merged so that I could be unblocked on applications of that, and when we find a better name for it, I can make NFC for that.
@chandlerc , how do you feel about this?

[mkazantsev]

Rebased.

[apilipenko]

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.

[mkazantsev]

In D51207#1312345, @apilipenko wrote:

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.

Current definition in LangRef gives it much wider use cases than this. The point is, we have no obligation to *only* use this intrinsic in and condition with deopt in one of branches. For example, this usage is legit:

if (wc()) {
  // Apply some solution that is fast on small data
} else {
  // Apply another alternative solution that is fast on big data
}

No deoptimize at all, but it is OK to make various optimizations that will play with heuristics when to choose which.

[mkazantsev]

Ping?

[reames]

LGTM w/minor comment to be addressed before landing.

Note: I am specific LGTMing this in the current form, despite the previously raised question about naming. Given the conversation appears to have died and this is in the experimental namespace allowing naming changes anyway, it's time to land this patch and then iterate in tree if needed. If anyone *actively objects* feel free to speak up, but let's not let bikeshedding block progress here if we can avoid it.

include/llvm/IR/Intrinsics.td

833 ↗

(On Diff #162330)

please remove the "for guards represented ..." part. The intrinsic is specified in a more generic manner than just for guards.

llvm/trunk/docs/LangRef.rst

 is ``false``.  Since the optimizer is allowed to replace the ``undef``
 with an arbitrary value, it can optimize guard to fail "spuriously",
 i.e. without the original condition being false (hence the "not only
 if"); and this allows for "check widening" type optimizations.
 
 ``@llvm.experimental.guard`` cannot be invoked.
 
 
+'``llvm.experimental.widenable.condition``' Intrinsic
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+
+::
+
+      declare i1 @llvm.experimental.widenable.condition()
+
+Overview:
+"""""""""
+
+This intrinsic represents a "widenable condition" which is
+boolean expressions with the following property: whether this
+expression is `true` or `false`, the program is correct and
+well-defined.
+
+Together with :ref:`deoptimization operand bundles <deopt_opbundles>`,
+``@llvm.experimental.widenable.condition`` allows frontends to
+express guards or checks on optimistic assumptions made during
+compilation and represent them as branch instructions on special
+conditions.
+
+While this may appear similar in semantics to `undef`, it is very
+different in that an invocation produces a particular, singular
+value. It is also intended to be lowered late, and remain available
+for specific optimizations and transforms that can benefit from its
+special properties.
+
+Arguments:
+""""""""""
+
+None.
+
+Semantics:
+""""""""""
+
+The intrinsic ``@llvm.experimental.widenable.condition()``
+returns either `true` or `false`. For each evaluation of a call
+to this intrinsic, the program must be valid and correct both if
+it returns `true` and if it returns `false`. This allows
+transformation passes to replace evaluations of this intrinsic
+with either value whenever one is beneficial.
+
+When used in a branch condition, it allows us to choose between
+two alternative correct solutions for the same problem, like
+in example below:
+
+.. code-block:: text
+
+    %cond = call i1 @llvm.experimental.widenable.condition()
+    br i1 %cond, label %solution_1, label %solution_2
+
+  label %fast_path:
+    ; Apply memory-consuming but fast solution for a task.
+
+  label %slow_path:
+    ; Cheap in memory but slow solution.
+
+Whether the result of intrinsic's call is `true` or `false`,
+it should be correct to pick either solution. We can switch
+between them by replacing the result of
+``@llvm.experimental.widenable.condition`` with different
+`i1` expressions.
+
+This is how it can be used to represent guards as widenable branches:
+
+.. code-block:: text
+
+  block:
+    ; Unguarded instructions
+    call void @llvm.experimental.guard(i1 %cond, <args...>) ["deopt"(<deopt_args...>)]
+    ; Guarded instructions
+
+Can be expressed in an alternative equivalent form of explicit branch using
+``@llvm.experimental.widenable.condition``:
+
+.. code-block:: text
+
+  block:
+    ; Unguarded instructions
+    %widenable_condition = call i1 @llvm.experimental.widenable.condition()
+    %guard_condition = and i1 %cond, %widenable_condition
+    br i1 %guard_condition, label %guarded, label %deopt
+
+  guarded:
+    ; Guarded instructions
+
+  deopt:
+    call type @llvm.experimental.deoptimize(<args...>) [ "deopt"(<deopt_args...>) ]
+
+So the block `guarded` is only reachable when `%cond` is `true`,
+and it should be valid to go to the block `deopt` whenever `%cond`
+is `true` or `false`.
+
+``@llvm.experimental.widenable.condition`` will never throw, thus
+it cannot be invoked.
+
+Guard widening:
+"""""""""""""""
+
+When ``@llvm.experimental.widenable.condition()`` is used in
+condition of a guard represented as explicit branch, it is
+legal to widen the guard's condition with any additional
+conditions.
+
+Guard widening looks like replacement of
+
+.. code-block:: text
+
+  %widenable_cond = call i1 @llvm.experimental.widenable.condition()
+  %guard_cond = and i1 %cond, %widenable_cond
+  br i1 %guard_cond, label %guarded, label %deopt
+
+with
+
+.. code-block:: text
+
+  %widenable_cond = call i1 @llvm.experimental.widenable.condition()
+  %new_cond = and i1 %any_other_cond, %widenable_cond
+  %new_guard_cond = and i1 %cond, %new_cond
+  br i1 %new_guard_cond, label %guarded, label %deopt
+
+for this branch. Here `%any_other_cond` is an arbitrarily chosen
+well-defined `i1` value. By making guard widening, we may
+impose stricter conditions on `guarded` block and bail to the
+deopt when the new condition is not met.
+
+Lowering:
+"""""""""
+
+Default lowering strategy is replacing the result of
+call of ``@llvm.experimental.widenable.condition``  with
+constant `true`. However it is always correct to replace
+it with any other `i1` value. Any pass can
+freely do it if it can benefit from non-default lowering.
+
+
 '``llvm.load.relative``' Intrinsic
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Syntax:
 """""""
 
 ::
 

llvm/trunk/include/llvm/IR/Intrinsics.td

 // Support for dynamic deoptimization (or de-specialization)
 def int_experimental_deoptimize : Intrinsic<[llvm_any_ty], [llvm_vararg_ty],
                                             [Throws]>;
 
 // Support for speculative runtime guards
 def int_experimental_guard : Intrinsic<[], [llvm_i1_ty, llvm_vararg_ty],
                                        [Throws]>;
 
+// Supports widenable conditions for guards represented as explicit branches.
+def int_experimental_widenable_condition : Intrinsic<[llvm_i1_ty], [],
+                                           [IntrInaccessibleMemOnly]>;
+
 // NOP: calls/invokes to this intrinsic are removed by codegen
 def int_donothing : Intrinsic<[], [], [IntrNoMem]>;
 
 // This instruction has no actual effect, though it is treated by the optimizer
 // has having opaque side effects. This may be inserted into loops to ensure
 // that they are not removed even if they turn out to be empty, for languages
 // which specify that infinite loops must be preserved.
 def int_sideeffect : Intrinsic<[], [], [IntrInaccessibleMemOnly]>;

llvm/trunk/include/llvm/InitializePasses.h

 void initializeEdgeBundlesPass(PassRegistry&);
 void initializeEfficiencySanitizerPass(PassRegistry&);
 void initializeEliminateAvailableExternallyLegacyPassPass(PassRegistry&);
 void initializeEntryExitInstrumenterPass(PassRegistry&);
 void initializeExpandISelPseudosPass(PassRegistry&);
 void initializeExpandMemCmpPassPass(PassRegistry&);
 void initializeExpandPostRAPass(PassRegistry&);
 void initializeExpandReductionsPass(PassRegistry&);
+void initializeMakeGuardsExplicitLegacyPassPass(PassRegistry&);
 void initializeExternalAAWrapperPassPass(PassRegistry&);
 void initializeFEntryInserterPass(PassRegistry&);
 void initializeFinalizeMachineBundlesPass(PassRegistry&);
 void initializeFlattenCFGPassPass(PassRegistry&);
 void initializeFloat2IntLegacyPassPass(PassRegistry&);
 void initializeForceFunctionAttrsLegacyPassPass(PassRegistry&);
 void initializeForwardControlFlowIntegrityPass(PassRegistry&);
 void initializeFuncletLayoutPass(PassRegistry&);

llvm/trunk/include/llvm/Transforms/Scalar/MakeGuardsExplicit.h

+//===-- MakeGuardsExplicit.h - Turn guard intrinsics into guard branches --===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===----------------------------------------------------------------------===//
+//
+// This pass lowers the @llvm.experimental.guard intrinsic to the new form of
+// guard represented as widenable explicit branch to the deopt block. The
+// difference between this pass and LowerGuardIntrinsic is that after this pass
+// the guard represented as intrinsic:
+//
+//   call void(i1, ...) @llvm.experimental.guard(i1 %old_cond) [ "deopt"() ]
+//
+// transforms to a guard represented as widenable explicit branch:
+//
+//   %widenable_cond = call i1 @llvm.experimental.widenable.condition()
+//   br i1 (%old_cond & %widenable_cond), label %guarded, label %deopt
+//
+// Here:
+//   - The semantics of @llvm.experimental.widenable.condition allows to replace
+//     %widenable_cond with the construction (%widenable_cond & %any_other_cond)
+//     without loss of correctness;
+//   - %guarded is the lower part of old guard intrinsic's parent block split by
+//     the intrinsic call;
+//   - %deopt is a block containing a sole call to @llvm.experimental.deoptimize
+//     intrinsic.
+//
+// Therefore, this branch preserves the property of widenability.
+//
+//===----------------------------------------------------------------------===//
+#ifndef LLVM_TRANSFORMS_SCALAR_MAKEGUARDSEXPLICIT_H
+#define LLVM_TRANSFORMS_SCALAR_MAKEGUARDSEXPLICIT_H
+
+#include "llvm/IR/PassManager.h"
+
+namespace llvm {
+
+struct MakeGuardsExplicitPass : public PassInfoMixin<MakeGuardsExplicitPass> {
+  PreservedAnalyses run(Function &F, FunctionAnalysisManager &AM);
+};
+
+} // namespace llvm
+
+#endif //LLVM_TRANSFORMS_SCALAR_MAKEGUARDSEXPLICIT_H

llvm/trunk/lib/Passes/PassBuilder.cpp

 #include "llvm/Transforms/Scalar/LoopSimplifyCFG.h"
 #include "llvm/Transforms/Scalar/LoopSink.h"
 #include "llvm/Transforms/Scalar/LoopStrengthReduce.h"
 #include "llvm/Transforms/Scalar/LoopUnrollAndJamPass.h"
 #include "llvm/Transforms/Scalar/LoopUnrollPass.h"
 #include "llvm/Transforms/Scalar/LowerAtomic.h"
 #include "llvm/Transforms/Scalar/LowerExpectIntrinsic.h"
 #include "llvm/Transforms/Scalar/LowerGuardIntrinsic.h"
+#include "llvm/Transforms/Scalar/MakeGuardsExplicit.h"
 #include "llvm/Transforms/Scalar/MemCpyOptimizer.h"
 #include "llvm/Transforms/Scalar/MergedLoadStoreMotion.h"
 #include "llvm/Transforms/Scalar/NaryReassociate.h"
 #include "llvm/Transforms/Scalar/NewGVN.h"
 #include "llvm/Transforms/Scalar/PartiallyInlineLibCalls.h"
 #include "llvm/Transforms/Scalar/Reassociate.h"
 #include "llvm/Transforms/Scalar/RewriteStatepointsForGC.h"
 #include "llvm/Transforms/Scalar/SCCP.h"

llvm/trunk/lib/Passes/PassRegistry.def

 FUNCTION_PASS("dce", DCEPass())
 FUNCTION_PASS("div-rem-pairs", DivRemPairsPass())
 FUNCTION_PASS("dse", DSEPass())
 FUNCTION_PASS("dot-cfg", CFGPrinterPass())
 FUNCTION_PASS("dot-cfg-only", CFGOnlyPrinterPass())
 FUNCTION_PASS("early-cse", EarlyCSEPass(/*UseMemorySSA=*/false))
 FUNCTION_PASS("early-cse-memssa", EarlyCSEPass(/*UseMemorySSA=*/true))
 FUNCTION_PASS("ee-instrument", EntryExitInstrumenterPass(/*PostInlining=*/false))
+FUNCTION_PASS("make-guards-explicit", MakeGuardsExplicitPass())
 FUNCTION_PASS("post-inline-ee-instrument", EntryExitInstrumenterPass(/*PostInlining=*/true))
 FUNCTION_PASS("gvn-hoist", GVNHoistPass())
 FUNCTION_PASS("instcombine", InstCombinePass())
 FUNCTION_PASS("instsimplify", InstSimplifyPass())
 FUNCTION_PASS("invalidate<all>", InvalidateAllAnalysesPass())
 FUNCTION_PASS("float2int", Float2IntPass())
 FUNCTION_PASS("no-op-function", NoOpFunctionPass())
 FUNCTION_PASS("libcalls-shrinkwrap", LibCallsShrinkWrapPass())

llvm/trunk/lib/Transforms/Scalar/CMakeLists.txt

add_llvm_library(LLVMScalarOpts
   LoopStrengthReduce.cpp
   LoopUnrollPass.cpp
   LoopUnrollAndJamPass.cpp
   LoopUnswitch.cpp
   LoopVersioningLICM.cpp
   LowerAtomic.cpp
   LowerExpectIntrinsic.cpp
   LowerGuardIntrinsic.cpp
+  MakeGuardsExplicit.cpp
   MemCpyOptimizer.cpp
   MergeICmps.cpp
   MergedLoadStoreMotion.cpp
   NaryReassociate.cpp
   NewGVN.cpp
   PartiallyInlineLibCalls.cpp
   PlaceSafepoints.cpp
   Reassociate.cpp

llvm/trunk/lib/Transforms/Scalar/MakeGuardsExplicit.cpp

+//===- MakeGuardsExplicit.cpp - Turn guard intrinsics into guard branches -===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===----------------------------------------------------------------------===//
+//
+// This pass lowers the @llvm.experimental.guard intrinsic to the new form of
+// guard represented as widenable explicit branch to the deopt block. The
+// difference between this pass and LowerGuardIntrinsic is that after this pass
+// the guard represented as intrinsic:
+//
+//   call void(i1, ...) @llvm.experimental.guard(i1 %old_cond) [ "deopt"() ]
+//
+// transforms to a guard represented as widenable explicit branch:
+//
+//   %widenable_cond = call i1 @llvm.experimental.widenable.condition()
+//   br i1 (%old_cond & %widenable_cond), label %guarded, label %deopt
+//
+// Here:
+//   - The semantics of @llvm.experimental.widenable.condition allows to replace
+//     %widenable_cond with the construction (%widenable_cond & %any_other_cond)
+//     without loss of correctness;
+//   - %guarded is the lower part of old guard intrinsic's parent block split by
+//     the intrinsic call;
+//   - %deopt is a block containing a sole call to @llvm.experimental.deoptimize
+//     intrinsic.
+//
+// Therefore, this branch preserves the property of widenability.
+//
+//===----------------------------------------------------------------------===//
+
+#include "llvm/Transforms/Scalar/MakeGuardsExplicit.h"
+#include "llvm/Analysis/GuardUtils.h"
+#include "llvm/IR/InstIterator.h"
+#include "llvm/IR/IntrinsicInst.h"
+#include "llvm/IR/Intrinsics.h"
+#include "llvm/IR/IRBuilder.h"
+#include "llvm/Pass.h"
+#include "llvm/Transforms/Scalar.h"
+#include "llvm/Transforms/Utils/GuardUtils.h"
+
+using namespace llvm;
+
+namespace {
+struct MakeGuardsExplicitLegacyPass : public FunctionPass {
+  static char ID;
+  MakeGuardsExplicitLegacyPass() : FunctionPass(ID) {
+    initializeMakeGuardsExplicitLegacyPassPass(*PassRegistry::getPassRegistry());
+  }
+
+  bool runOnFunction(Function &F) override;
+};
+}
+
+static void turnToExplicitForm(CallInst *Guard, Function *DeoptIntrinsic) {
+  // Replace the guard with an explicit branch (just like in GuardWidening).
+  BasicBlock *BB = Guard->getParent();
+  makeGuardControlFlowExplicit(DeoptIntrinsic, Guard);
+  BranchInst *ExplicitGuard = cast<BranchInst>(BB->getTerminator());
+  assert(ExplicitGuard->isConditional() && "Must be!");
+
+  // We want the guard to be expressed as explicit control flow, but still be
+  // widenable. For that, we add Widenable Condition intrinsic call to the
+  // guard's condition.
+  IRBuilder<> B(ExplicitGuard);
+  auto *WidenableCondition =
+      B.CreateIntrinsic(Intrinsic::experimental_widenable_condition,
+                        {}, {}, nullptr, "widenable_cond");
+  WidenableCondition->setCallingConv(Guard->getCallingConv());
+  auto *NewCond =
+      B.CreateAnd(ExplicitGuard->getCondition(), WidenableCondition);
+  NewCond->setName("exiplicit_guard_cond");
+  ExplicitGuard->setCondition(NewCond);
+  Guard->eraseFromParent();
+}
+
+static bool explicifyGuards(Function &F) {
+  // Check if we can cheaply rule out the possibility of not having any work to
+  // do.
+  auto *GuardDecl = F.getParent()->getFunction(
+      Intrinsic::getName(Intrinsic::experimental_guard));
+  if (!GuardDecl || GuardDecl->use_empty())
+    return false;
+
+  SmallVector<CallInst *, 8> GuardIntrinsics;
+  for (auto &I : instructions(F))
+    if (isGuard(&I))
+      GuardIntrinsics.push_back(cast<CallInst>(&I));
+
+  if (GuardIntrinsics.empty())
+    return false;
+
+  auto *DeoptIntrinsic = Intrinsic::getDeclaration(
+      F.getParent(), Intrinsic::experimental_deoptimize, {F.getReturnType()});
+  DeoptIntrinsic->setCallingConv(GuardDecl->getCallingConv());
+
+  for (auto *Guard : GuardIntrinsics)
+    turnToExplicitForm(Guard, DeoptIntrinsic);
+
+  return true;
+}
+
+bool MakeGuardsExplicitLegacyPass::runOnFunction(Function &F) {
+  return explicifyGuards(F);
+}
+
+char MakeGuardsExplicitLegacyPass::ID = 0;
+INITIALIZE_PASS(MakeGuardsExplicitLegacyPass, "make-guards-explicit",
+                "Lower the guard intrinsic to explicit control flow form",
+                false, false)
+
+PreservedAnalyses MakeGuardsExplicitPass::run(Function &F,
+                                           FunctionAnalysisManager &) {
+  if (explicifyGuards(F))
+    return PreservedAnalyses::none();
+  return PreservedAnalyses::all();
+}

llvm/trunk/lib/Transforms/Scalar/Scalar.cpp

void llvm::initializeScalarOpts(PassRegistry &Registry) {
   initializeScalarizerLegacyPassPass(Registry);
   initializeDSELegacyPassPass(Registry);
   initializeGuardWideningLegacyPassPass(Registry);
   initializeLoopGuardWideningLegacyPassPass(Registry);
   initializeGVNLegacyPassPass(Registry);
   initializeNewGVNLegacyPassPass(Registry);
   initializeEarlyCSELegacyPassPass(Registry);
   initializeEarlyCSEMemSSALegacyPassPass(Registry);
+  initializeMakeGuardsExplicitLegacyPassPass(Registry);
   initializeGVNHoistLegacyPassPass(Registry);
   initializeGVNSinkLegacyPassPass(Registry);
   initializeFlattenCFGPassPass(Registry);
   initializeIRCELegacyPassPass(Registry);
   initializeIndVarSimplifyLegacyPassPass(Registry);
   initializeInferAddressSpacesPass(Registry);
   initializeInstSimplifyLegacyPassPass(Registry);
   initializeJumpThreadingPass(Registry);

llvm/trunk/test/Transforms/LICM/explicit_guards.ll

+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
+; RUN: opt -S -make-guards-explicit -basicaa -licm < %s        | FileCheck %s
+; RUN: opt -S -aa-pipeline=basic-aa -passes='require<opt-remark-emit>,make-guards-explicit,loop(licm)' < %s | FileCheck %s
+
+; Test interaction between explicit guards and LICM: make sure that we do not
+; hoist explicit conditions while we can hoist invariant loads in presence of
+; explicit guards.
+
+declare void @llvm.experimental.guard(i1,...)
+
+; Make sure that we do not hoist widenable_cond out of loop.
+define void @do_not_hoist_widenable_cond(i1 %cond, i32 %N, i32 %M) {
+; CHECK-LABEL: @do_not_hoist_widenable_cond(
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:    br label [[LOOP:%.*]]
+; CHECK:       loop:
+; CHECK-NEXT:    [[IV:%.*]] = phi i32 [ 0, [[ENTRY:%.*]] ], [ [[IV_NEXT:%.*]], [[GUARDED:%.*]] ]
+; CHECK-NEXT:    [[GUARD_COND:%.*]] = icmp slt i32 [[IV]], [[N:%.*]]
+; CHECK-NEXT:    [[WIDENABLE_COND:%.*]] = call i1 @llvm.experimental.widenable.condition()
+; CHECK-NEXT:    [[EXIPLICIT_GUARD_COND:%.*]] = and i1 [[GUARD_COND]], [[WIDENABLE_COND]]
+; CHECK-NEXT:    br i1 [[EXIPLICIT_GUARD_COND]], label [[GUARDED]], label [[DEOPT:%.*]], !prof !0
+; CHECK:       deopt:
+; CHECK-NEXT:    call void (...) @llvm.experimental.deoptimize.isVoid() [ "deopt"() ]
+; CHECK-NEXT:    ret void
+; CHECK:       guarded:
+; CHECK-NEXT:    [[LOOP_COND:%.*]] = icmp slt i32 [[IV]], [[M:%.*]]
+; CHECK-NEXT:    [[IV_NEXT]] = add i32 [[IV]], 1
+; CHECK-NEXT:    br i1 [[LOOP_COND]], label [[LOOP]], label [[EXIT:%.*]]
+; CHECK:       exit:
+; CHECK-NEXT:    ret void
+;
+entry:
+  br label %loop
+
+loop:
+  %iv = phi i32 [ 0, %entry ], [ %iv.next, %loop ]
+  %guard_cond = icmp slt i32 %iv, %N
+  call void(i1, ...) @llvm.experimental.guard(i1 %guard_cond) [ "deopt"() ]
+  %loop_cond = icmp slt i32 %iv, %M
+  %iv.next = add i32 %iv, 1
+  br i1 %loop_cond, label %loop, label %exit
+
+exit:
+  ret void
+}
+
+define void @hoist_invariant_load(i1 %cond, i32* %np, i32 %M) {
+; CHECK-LABEL: @hoist_invariant_load(
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:    [[N:%.*]] = load i32, i32* [[NP:%.*]]
+; CHECK-NEXT:    br label [[LOOP:%.*]]
+; CHECK:       loop:
+; CHECK-NEXT:    [[IV:%.*]] = phi i32 [ 0, [[ENTRY:%.*]] ], [ [[IV_NEXT:%.*]], [[GUARDED:%.*]] ]
+; CHECK-NEXT:    [[GUARD_COND:%.*]] = icmp slt i32 [[IV]], [[N]]
+; CHECK-NEXT:    [[WIDENABLE_COND:%.*]] = call i1 @llvm.experimental.widenable.condition()
+; CHECK-NEXT:    [[EXIPLICIT_GUARD_COND:%.*]] = and i1 [[GUARD_COND]], [[WIDENABLE_COND]]
+; CHECK-NEXT:    br i1 [[EXIPLICIT_GUARD_COND]], label [[GUARDED]], label [[DEOPT:%.*]], !prof !0
+; CHECK:       deopt:
+; CHECK-NEXT:    call void (...) @llvm.experimental.deoptimize.isVoid() [ "deopt"() ]
+; CHECK-NEXT:    ret void
+; CHECK:       guarded:
+; CHECK-NEXT:    [[LOOP_COND:%.*]] = icmp slt i32 [[IV]], [[M:%.*]]
+; CHECK-NEXT:    [[IV_NEXT]] = add i32 [[IV]], 1
+; CHECK-NEXT:    br i1 [[LOOP_COND]], label [[LOOP]], label [[EXIT:%.*]]
+; CHECK:       exit:
+; CHECK-NEXT:    ret void
+;
+entry:
+  br label %loop
+
+loop:
+  %iv = phi i32 [ 0, %entry ], [ %iv.next, %loop ]
+  %N = load i32, i32* %np
+  %guard_cond = icmp slt i32 %iv, %N
+  call void(i1, ...) @llvm.experimental.guard(i1 %guard_cond) [ "deopt"() ]
+  %loop_cond = icmp slt i32 %iv, %M
+  %iv.next = add i32 %iv, 1
+  br i1 %loop_cond, label %loop, label %exit
+
+exit:
+  ret void
+}

llvm/trunk/test/Transforms/MakeGuardsExplicit/basic.ll

+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
+; RUN: opt -S -make-guards-explicit < %s        | FileCheck %s
+; RUN: opt -S -passes=make-guards-explicit < %s | FileCheck %s
+
+declare void @llvm.experimental.guard(i1,...)
+
+; Check that a sole guard can be turned into explicit guards form.
+define void @trivial_guard(i1 %cond) {
+; CHECK-LABEL: @trivial_guard(
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:    [[WIDENABLE_COND:%.*]] = call i1 @llvm.experimental.widenable.condition()
+; CHECK-NEXT:    [[EXIPLICIT_GUARD_COND:%.*]] = and i1 [[COND:%.*]], [[WIDENABLE_COND]]
+; CHECK-NEXT:    br i1 [[EXIPLICIT_GUARD_COND]], label [[GUARDED:%.*]], label [[DEOPT:%.*]], !prof !0
+; CHECK:       deopt:
+; CHECK-NEXT:    call void (...) @llvm.experimental.deoptimize.isVoid() [ "deopt"(i32 123, i64 456) ]
+; CHECK-NEXT:    ret void
+; CHECK:       guarded:
+; CHECK-NEXT:    ret void
+;
+entry:
+  call void(i1, ...) @llvm.experimental.guard(i1 %cond) [ "deopt"(i32 123, i64 456) ]
+  ret void
+}
+
+; Check that a sequence of guards can be turned into explicit guards form.
+define void @trivial_guard_sequence(i1 %cond1, i1 %cond2, i1 %cond3) {
+; CHECK-LABEL: @trivial_guard_sequence(
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:    [[WIDENABLE_COND:%.*]] = call i1 @llvm.experimental.widenable.condition()
+; CHECK-NEXT:    [[EXIPLICIT_GUARD_COND:%.*]] = and i1 [[COND1:%.*]], [[WIDENABLE_COND]]
+; CHECK-NEXT:    br i1 [[EXIPLICIT_GUARD_COND]], label [[GUARDED:%.*]], label [[DEOPT:%.*]], !prof !0
+; CHECK:       deopt:
+; CHECK-NEXT:    call void (...) @llvm.experimental.deoptimize.isVoid() [ "deopt"(i32 123, i64 456) ]
+; CHECK-NEXT:    ret void
+; CHECK:       guarded:
+; CHECK-NEXT:    [[WIDENABLE_COND3:%.*]] = call i1 @llvm.experimental.widenable.condition()
+; CHECK-NEXT:    [[EXIPLICIT_GUARD_COND4:%.*]] = and i1 [[COND2:%.*]], [[WIDENABLE_COND3]]
+; CHECK-NEXT:    br i1 [[EXIPLICIT_GUARD_COND4]], label [[GUARDED1:%.*]], label [[DEOPT2:%.*]], !prof !0
+; CHECK:       deopt2:
+; CHECK-NEXT:    call void (...) @llvm.experimental.deoptimize.isVoid() [ "deopt"(i32 789, i64 123) ]
+; CHECK-NEXT:    ret void
+; CHECK:       guarded1:
+; CHECK-NEXT:    [[WIDENABLE_COND7:%.*]] = call i1 @llvm.experimental.widenable.condition()
+; CHECK-NEXT:    [[EXIPLICIT_GUARD_COND8:%.*]] = and i1 [[COND3:%.*]], [[WIDENABLE_COND7]]
+; CHECK-NEXT:    br i1 [[EXIPLICIT_GUARD_COND8]], label [[GUARDED5:%.*]], label [[DEOPT6:%.*]], !prof !0
+; CHECK:       deopt6:
+; CHECK-NEXT:    call void (...) @llvm.experimental.deoptimize.isVoid() [ "deopt"(i32 456, i64 789) ]
+; CHECK-NEXT:    ret void
+; CHECK:       guarded5:
+; CHECK-NEXT:    ret void
+;
+entry:
+  call void(i1, ...) @llvm.experimental.guard(i1 %cond1) [ "deopt"(i32 123, i64 456) ]
+  call void(i1, ...) @llvm.experimental.guard(i1 %cond2) [ "deopt"(i32 789, i64 123) ]
+  call void(i1, ...) @llvm.experimental.guard(i1 %cond3) [ "deopt"(i32 456, i64 789) ]
+  ret void
+}
+
+; Check that all instructions between the guards preserve.
+define void @split_block_contents(i1 %cond1, i1 %cond2, i1 %cond3, i32* %p) {
+; CHECK-LABEL: @split_block_contents(
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:    store i32 0, i32* [[P:%.*]]
+; CHECK-NEXT:    [[WIDENABLE_COND:%.*]] = call i1 @llvm.experimental.widenable.condition()
+; CHECK-NEXT:    [[EXIPLICIT_GUARD_COND:%.*]] = and i1 [[COND1:%.*]], [[WIDENABLE_COND]]
+; CHECK-NEXT:    br i1 [[EXIPLICIT_GUARD_COND]], label [[GUARDED:%.*]], label [[DEOPT:%.*]], !prof !0
+; CHECK:       deopt:
+; CHECK-NEXT:    call void (...) @llvm.experimental.deoptimize.isVoid() [ "deopt"(i32 123, i64 456) ]
+; CHECK-NEXT:    ret void
+; CHECK:       guarded:
+; CHECK-NEXT:    store i32 1, i32* [[P]]
+; CHECK-NEXT:    [[WIDENABLE_COND3:%.*]] = call i1 @llvm.experimental.widenable.condition()
+; CHECK-NEXT:    [[EXIPLICIT_GUARD_COND4:%.*]] = and i1 [[COND2:%.*]], [[WIDENABLE_COND3]]
+; CHECK-NEXT:    br i1 [[EXIPLICIT_GUARD_COND4]], label [[GUARDED1:%.*]], label [[DEOPT2:%.*]], !prof !0
+; CHECK:       deopt2:
+; CHECK-NEXT:    call void (...) @llvm.experimental.deoptimize.isVoid() [ "deopt"(i32 789, i64 123) ]
+; CHECK-NEXT:    ret void
+; CHECK:       guarded1:
+; CHECK-NEXT:    store i32 2, i32* [[P]]
+; CHECK-NEXT:    [[WIDENABLE_COND7:%.*]] = call i1 @llvm.experimental.widenable.condition()
+; CHECK-NEXT:    [[EXIPLICIT_GUARD_COND8:%.*]] = and i1 [[COND3:%.*]], [[WIDENABLE_COND7]]
+; CHECK-NEXT:    br i1 [[EXIPLICIT_GUARD_COND8]], label [[GUARDED5:%.*]], label [[DEOPT6:%.*]], !prof !0
+; CHECK:       deopt6:
+; CHECK-NEXT:    call void (...) @llvm.experimental.deoptimize.isVoid() [ "deopt"(i32 456, i64 789) ]
+; CHECK-NEXT:    ret void
+; CHECK:       guarded5:
+; CHECK-NEXT:    store i32 3, i32* [[P]]
+; CHECK-NEXT:    ret void
+;
+entry:
+  store i32 0, i32* %p
+  call void(i1, ...) @llvm.experimental.guard(i1 %cond1) [ "deopt"(i32 123, i64 456) ]
+  store i32 1, i32* %p
+  call void(i1, ...) @llvm.experimental.guard(i1 %cond2) [ "deopt"(i32 789, i64 123) ]
+  store i32 2, i32* %p
+  call void(i1, ...) @llvm.experimental.guard(i1 %cond3) [ "deopt"(i32 456, i64 789) ]
+  store i32 3, i32* %p
+  ret void
+}
+
+; Check that the guard can split a loop properly.
+define void @split_loop(i1 %cond, i32 %N, i32 %M) {
+; CHECK-LABEL: @split_loop(
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:    br label [[LOOP:%.*]]
+; CHECK:       loop:
+; CHECK-NEXT:    [[IV:%.*]] = phi i32 [ 0, [[ENTRY:%.*]] ], [ [[IV_NEXT:%.*]], [[GUARDED:%.*]] ]
+; CHECK-NEXT:    [[GUARD_COND:%.*]] = icmp slt i32 [[IV]], [[N:%.*]]
+; CHECK-NEXT:    [[WIDENABLE_COND:%.*]] = call i1 @llvm.experimental.widenable.condition()
+; CHECK-NEXT:    [[EXIPLICIT_GUARD_COND:%.*]] = and i1 [[GUARD_COND]], [[WIDENABLE_COND]]
+; CHECK-NEXT:    br i1 [[EXIPLICIT_GUARD_COND]], label [[GUARDED]], label [[DEOPT:%.*]], !prof !0
+; CHECK:       deopt:
+; CHECK-NEXT:    call void (...) @llvm.experimental.deoptimize.isVoid() [ "deopt"(i32 123, i64 456) ]
+; CHECK-NEXT:    ret void
+; CHECK:       guarded:
+; CHECK-NEXT:    [[LOOP_COND:%.*]] = icmp slt i32 [[IV]], [[M:%.*]]
+; CHECK-NEXT:    [[IV_NEXT]] = add i32 [[IV]], 1
+; CHECK-NEXT:    br i1 [[LOOP_COND]], label [[LOOP]], label [[EXIT:%.*]]
+; CHECK:       exit:
+; CHECK-NEXT:    ret void
+;
+entry:
+  br label %loop
+
+loop:
+  %iv = phi i32 [ 0, %entry ], [ %iv.next, %loop ]
+  %guard_cond = icmp slt i32 %iv, %N
+  call void(i1, ...) @llvm.experimental.guard(i1 %guard_cond) [ "deopt"(i32 123, i64 456) ]
+  %loop_cond = icmp slt i32 %iv, %M
+  %iv.next = add i32 %iv, 1
+  br i1 %loop_cond, label %loop, label %exit
+
+exit:
+  ret void
+}