| Issue |
181188
|
| Summary |
IndVars fails to remove range check after signed -> unsigned canonicalization
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
xortator
|
Repro: https://godbolt.org/z/dqaTdYTcs
Run `opt -indvars` on
```
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
define void @func_22(ptr %length.ptr) {
entry:
%length = load i32, ptr %length.ptr, !range !0
%lim = sub i32 %length, 1
%entry.cond = icmp sgt i32 %length, 1
br i1 %entry.cond, label %loop, label %leave
loop:
%iv = phi i32 [ 0, %entry ], [ %iv.inc, %be ]
%iv.inc = add i32 %iv, 1
%range.check = icmp sle i32 %iv, %length
br i1 %range.check, label %be, label %leave
be:
call void @side_effect()
%be.cond = icmp sle i32 %iv.inc, %lim
br i1 %be.cond, label %loop, label %leave
leave:
ret void
}
define void @func_22_bad(ptr %length.ptr) {
entry:
%length = load i32, ptr %length.ptr, !range !0
%lim = sub i32 %length, 1
%entry.cond = icmp sgt i32 %length, 1
br i1 %entry.cond, label %loop, label %leave
loop:
%iv = phi i32 [ 0, %entry ], [ %iv.inc, %be ]
%iv.inc = add i32 %iv, 1
%range.check = icmp sle i32 %iv, %length
br i1 %range.check, label %be, label %leave
be:
call void @side_effect()
%be.cond = icmp samesign ule i32 %iv.inc, %lim
br i1 %be.cond, label %loop, label %leave
leave:
ret void
}
declare void @side_effect()
!0 = !{i32 0, i32 2147483647}
```
The difference between the two functions above is that in the "bad" function we could prove that `lim >s 0` (inferred from `length > 1`, and `iv` is also non-negative because backedge leaves when `iv.next` reaches 2147483647. So both are non-negative and can be compared as `samesign ule`. But for some reason it pessimizes range check elimination and it gets replaced with `ne` but not removed.
The issue showed up on PR https://github.com/llvm/llvm-project/pull/181093 which makes unsigned/samesign inference smarter, but also exists in main branch already.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
