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.
20 KiB
20 KiB