[all-commits] [llvm/llvm-project] 1d4801: [mlir] fix `maybeReplaceWithConstant` in IntRangeO...

Maksim Levental via All-commits all-commits at lists.llvm.org
Fri Mar 28 20:28:33 PDT 2025


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1d4801f22ab1fd6205b1cf625b690aefc554cd4c
      https://github.com/llvm/llvm-project/commit/1d4801f22ab1fd6205b1cf625b690aefc554cd4c
  Author: Maksim Levental <maksim.levental at gmail.com>
  Date:   2025-03-28 (Fri, 28 Mar 2025)

  Changed paths:
    M mlir/lib/Dialect/Arith/Transforms/IntRangeOptimizations.cpp

  Log Message:
  -----------
  [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.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications


More information about the All-commits mailing list