tree 43e4cc4338d85c37e6a8c8cd91a0bbfd315111e1
parent 63bb0078f824143f580225ad92464b21186f646e
author Maksim Levental <maksim.levental@gmail.com> 1743218891 -0400
committer GitHub <noreply@github.com> 1743218891 -0400
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJn52jMCRC1aQ7uu5UhlAAAiboQACEVAnmJcgILPtrLCiCs3oii
 +ZnNYS99Sn4yUbrzSLyxVEbT3ZuqasLlhxa/QpwH8eQFBZA/FmI11KPoAHUL6fat
 4C5sax3evuVuzeAFgizeYSaclF6ejtZbGcj9qL9MGaZcZSLCDWy8aoYuPjfjBWO2
 Xau0vRd/ec+VA02efFm87/YPYO6fXX4C0IafQIvMxkJmDsRi+AGnjsAJhcelbIkp
 zpOSdgM7CmVB2huj1gsMWXOA+whkBkx5RLoLnZ3pzSYJvq5OlC8DGrUXshCD6fw1
 3fJEcMc23OYEhtrme8q2IApiw6NpMtBDsWjE9gK7V77IHypAvLr6bGwsys9BkNA0
 WW0TahNH+HzA+3a4j/Bibaoui/8tYhMhRIq6myMVFjiE3LVJp5Q/zfp3oL6s+sqr
 mKey1kHgMebGh3aqMVmyUqrunPsMCm0o0/Sbkt0j0mu+RRHEyU98Ni4AN6gcrKqI
 2MB8f+72aXqFrgq2VwGQ5/AOGLJRGE4nJXbDWiJm/0JfaExHLs/kdb1c2zZFIWsS
 09iQukEl/DnTIVNZo2FUnmK4zpHGwf/NUxExn0ohYWmazyK+9tj6MNfkMs0ksDVZ
 knkxzaqkTl0Vsr72aa72O3mMe+ioQlvKNWhpF4heSGcQBcdYV1lvZiNLtyhejNFX
 M4uQKU5oI2/biQCB4XOX
 =cDSo
 -----END PGP SIGNATURE-----
 

[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.