I noticed that the util-optimize-int-arithmetic pass, sometimes was incorrectly optimizing away operations. I tracked the issue down to the fact that AssumeIntOp::inferResultRanges doesn't always call setResultRange. Looking at the docs for InferIntRangeInterface in LLVM, it suggests that setResultRange must be called for each result, and looking further it's clear that some of the arith op folders rely on the fact that the range is always set (eg. arith.select).
This PR updates AssumeIntOp::inferResultRanges to call setResultRange even when umin or umax are not set.
I added a test case that used to be optimized to an incorrect constant, and now is not optimized out.
I noticed that the util-optimize-int-arithmetic pass, sometimes was incorrectly optimizing away operations. I tracked the issue down to the fact that
AssumeIntOp::inferResultRanges
doesn't always callsetResultRange
. Looking at the docs forInferIntRangeInterface
in LLVM, it suggests thatsetResultRange
must be called for each result, and looking further it's clear that some of thearith
op folders rely on the fact that the range is always set (eg.arith.select
).This PR updates
AssumeIntOp::inferResultRanges
to callsetResultRange
even when umin or umax are not set.I added a test case that used to be optimized to an incorrect constant, and now is not optimized out.