This is a follow up for the loop predication change D37569 to support ule, sle latch predicates.
Details
Diff Detail
Event Timeline
test/Transforms/LoopPredication/basic.ll | ||
---|---|---|
158 | 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? |
test/Transforms/LoopPredication/basic.ll | ||
---|---|---|
158 | 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. |
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?