| Issue |
87015
|
| Summary |
[InstCombine] Unable to reach fixed point in 1 iteration when new folds are unblocked by knownbits.
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
goldsteinn
|
Take the following examples:
```
define i8 @src(i8 %x, i8 %y, i8 %z) {
%cmp = icmp eq i8 %x, %y
%conv16 = zext i1 %cmp to i16
%conv8 = zext i1 %cmp to i8
%r = add i8 %conv8, %z
%cmp_assume = icmp eq i16 %conv16, 0
call void @llvm.assume(i1 %cmp_assume)
ret i8 %r
}
```
When run with `opt -passes=instcombine` we run into:
```
LLVM ERROR: Instruction Combining did not reach a fixpoint after 1 iterations
```
https://godbolt.org/z/6Exn4r8jc
The issue is because we try to transform the `%r = add i8 %conv8, %z`
before we get to the `%cmp_assume = icmp eq i16 %conv16, 0`.
But we end up transform `%cmp_assume = icmp eq i16 %conv16, 0`
-> `%cmp_assume = icmp eq i1 %cmp, false` which, with the `assume`,
we are able to use to prove `%cmp` is `false` and thus `%conv8` is `0`
and then on iteration two simplifying the `%r = add i8 %conv8, %z`.
This particular cases is pretty easy to solve by supporting `(zext/sext op)`
in the AssumptionCache, but you could really generate any amount of
these issues by having a fold create a pattern we recognize in
`computeKnownBitsFromCmp` and a having a prior node that
we will only fold w/ certain known bits.
I think the fix is that when we add an `assume`, we need to
also add all instructions in its `AssumptionCache`.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
