[Mlir-commits] [mlir] [mlir][affine] avoid folding affine expressions that overflow int64_t (PR #231085)

[llvmlistbot at llvm.org]

lipracer wrote:

Just to clarify my earlier comment: I'm not suggesting that this PR is incomplete or that the current fix should be blocked.

My concern is with the general approach of addressing integer overflow through individual checks at each arithmetic operation.

Affine expressions are mathematical objects, but their implementation relies on fixed-width integers. Using `int64_t` is a reasonable engineering trade-off for real-world workloads, where the range is typically sufficient. However, fuzzers can easily construct inputs that violate this assumption.

Adding overflow checks at individual sites addresses known cases, but doesn't establish a system-wide guarantee that other arithmetic paths won't overflow.

A more systematic solution would be to use dynamically extensible integer representations at the underlying AffineExpr level, or to adopt a substantially wider representation if practical coverage is the goal.

Alternatively, retaining `int64_t` would ideally require a centralized checked-arithmetic abstraction with consistent overflow handling throughout the implementation.

This is a broader architectural consideration rather than a request for changes to this PR.

https://github.com/llvm/llvm-project/pull/231085