diff options
author | Maksim Levental <maksim.levental@gmail.com> | 2025-03-28 23:28:11 -0400 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-03-28 23:28:11 -0400 |
commit | 1d4801f22ab1fd6205b1cf625b690aefc554cd4c (patch) | |
tree | 43e4cc4338d85c37e6a8c8cd91a0bbfd315111e1 /llvm/lib/CodeGen | |
parent | 63bb0078f824143f580225ad92464b21186f646e (diff) | |
download | llvm-1d4801f22ab1fd6205b1cf625b690aefc554cd4c.zip llvm-1d4801f22ab1fd6205b1cf625b690aefc554cd4c.tar.gz llvm-1d4801f22ab1fd6205b1cf625b690aefc554cd4c.tar.bz2 |
[mlir] fix `maybeReplaceWithConstant` in IntRangeOptimizations (#133556)
If a dialect is caching/reusing constants when materializing then such
constants might already have `IntegerValueRangeLattice`s associated with
them and the range endpoint bit widths might not match the new
replacement (amongst other possible wackiness).
I observed this with `%true = arith.constant true` which was
materialized but had an existing `IntegerValueRangeLattice` (i.e.,
`solver.getOrCreateState<dataflow::IntegerValueRangeLattice>` was not
uninitalized) with range endpoint bit widths:
```
umin bit width: 32
umax bit width: 32
smin bit width: 32
smax bit width: 32
```
while the widths of the range end points for something like `%20 =
arith.cmpi slt, %19, %c1_i32` (a replacement candidate) would be
```
umin bit width: 1
umax bit width: 1
smin bit width: 1
smax bit width: 1
```
Thus, we should be clearing the analysis state each time a constant is
reused.
Diffstat (limited to 'llvm/lib/CodeGen')
0 files changed, 0 insertions, 0 deletions