[IRCE] Relax restriction on collected range checks

In IRCE, we have a very old legacy check that works when we collect comparisons that we
treat as range checks. It ensures that the value against which the indvar is compared is
loop invariant and is also positive.

This latter condition remained there since the times when IRCE was only able to handle
signed latch comparison. As the optimization evolved, it now learned how to intersect
signed or unsigned ranges, and this logic has no reliance on the fact that the right border
of each range should be positive.

The old implementation of this non-negativity check was also naive enough and just looked
into ranges (while most of other IRCE logic tries to use power of SCEV implications), so this
check did not allow to deal with the most simple case that looks like follows:

  int size; // not known non-negative
  int length; //known non-negative;
  i = 0;
  if (size != 0) {
    do {
      range_check(i < size);
      range_check(i < length);
    ++i;
    } while (i < size)
  }

In this case, even if from some dominating conditions IRCE could parse loop
structure, it could only remove the range check against `length` and simply
ignored the check against `size`.

In this patch we remove this obsolete check. It will allow IRCE to pick comparison
against `size` as a potential range check and then let Range Intersection logic
decide whether it is OK to eliminate it or not.

Differential Revision: https://reviews.llvm.org/D45362
Reviewed By: samparker

llvm-svn: 329547

1 files changed, 6 insertions, 6 deletions

diff --git a/llvm/test/Transforms/IRCE/range_intersect_miscompile.ll b/llvm/test/Transforms/IRCE/range_intersect_miscompile.ll
index cd4a52b62f5..489f34f70ac 100644
--- a/llvm/test/Transforms/IRCE/range_intersect_miscompile.ll
+++ b/llvm/test/Transforms/IRCE/range_intersect_miscompile.ll
@@ -168,20 +168,20 @@ deopt:                                          ; preds = %range_check_block
   ret void
 }
 
-; We do not know whether %n is positive or negative, so we prohibit IRCE in
-; order to avoid incorrect intersection of signed and unsigned ranges.
-; The condition %tmp2 can be eliminated.
+; We can also properly eliminate range check against %n which is not always
+; known positive.
 
 define void @test_04(i32* %p) {
 
 ; CHECK-LABEL: test_04
+; CHECK:       entry
 ; CHECK-NOT:   preloop
-; CHECK-NOT:   postloop
 ; CHECK:         %tmp2 = icmp sgt i32 %iv.prev, -1
 ; CHECK-NEXT:    br i1 true, label %loop_header.split.us, label %exit
 ; CHECK:       range_check_block:
 ; CHECK-NEXT:    %range_check = icmp slt i32 %iv, %n
-; CHECK-NEXT:    br i1 %range_check, label %loop_latch, label %deopt
+; CHECK-NEXT:    br i1 true, label %loop_latch, label %deopt
+; CHECK:       postloop:
 
 entry:
   %n = load i32, i32* %p
@@ -226,7 +226,7 @@ define void @test_05(i32* %p) {
 ; CHECK-LABEL: test_05
 ; CHECK-NOT:     preloop
 ; CHECK:         entry:
-; CHECK-NEXT:      %n = load i32, i32* %p, !range !6
+; CHECK-NEXT:      %n = load i32, i32* %p, !range !
 ; CHECK-NEXT:      [[CMP_1:%[^ ]+]] = icmp ugt i32 %n, 2
 ; CHECK-NEXT:      %exit.mainloop.at = select i1 [[CMP_1]], i32 %n, i32 2
 ; CHECK-NEXT:      [[CMP_2:%[^ ]+]] = icmp ult i32 2, %exit.mainloop.at