As LoopPredication performs non-equivalent transforms removing some checks from loops, other passes may not be able to perform transforms they'd be able to do if the checks were left in loops.
For example, LoopPredication may turn a range check expressed via widenable condition like this
loop: %iv.1 = phi i32 [ %iv.1.start, %entry ], [ %iv.1.next, %latch ] %cond.1 = icmp ult i32 %iv.1, %iv.1.end %wc = call i1 @llvm.experimental.widenable.condition() %explicit_guard_cond = and i1 %cond.1, %wc br i1 %explicit_guard_cond, label %loop.next, label %deopt
into an invariant check above loop.
Other passes may not be able to figure the fact that the new condition implies the old one, so such branch in %loop.next block:
loop.next: br i1 %cond.1, label %if.true, label %if.false
wouldn't get optimized.
This patch makes LoopPredication insert assumes of the replaced conditions either after a guard call or in the true block of widenable condition branch.
It's no longer dead.