[PATCH] D38177: [LoopPredication] Support ule, sle latch predicates

[Artur Pilipenko via Phabricator via llvm-commits]

apilipenko added inline comments.


================
Comment at: test/Transforms/LoopPredication/basic.ll:158
+; CHECK: loop.preheader:
+; CHECK: [[first_iteration_check:[^ ]+]] = icmp ult i32 0, %length
+; CHECK-NEXT: [[limit_check:[^ ]+]] = icmp slt i32 %n, %length
----------------
mkazantsev wrote:
> Consider case `%n = 10, %length = -100`. The original code will successfully pass through the guard (because `0 <u -100` is true) and then executes normally. After the loop is predicated, the condition `icmp slt i32 %n, %length` becomes false, and we don't go to the loop and deoptimize. Is it a problem?
>From correctness standpoint it's OK since guards are allowed to fail spuriously.

As of why it is happening, we find the first value the guard will fail (-100) and then check that the backedge condition doesn't allow this value. We are not using the information about the backedge IV start, so we end up with an overly conservative check.

It should not be a problem in practice as long as your language doesn't use arrays longer that max signed int.


https://reviews.llvm.org/D38177