[Mlir-commits] [mlir] [mlir] Handle attempted construction of invalid `AffineExpr` products (PR #103010)

[Felix Schneider]

ubfx wrote:

> I don't know if that is a hard and fast rule

At least in theory, it probably is:
https://github.com/llvm/llvm-project/blob/main/mlir/docs/Dialects/Affine.md#affine-expressions

https://github.com/llvm/llvm-project/blob/f5ba3f6740ff13c46da6d3306e39b026f2d15c5a/mlir/include/mlir/IR/AffineExpr.h#L40-L50

> and it seems like it could be changed based on the usage.

I agree, there's cases where `AffineExpr`s are used as a utility to temporarily hold some non-affine expression, like the example shown above.
On the other hand, an implementation using an `AffineExpr` **should** be able to rely on the fundamental promise of the expression actually being affine. Otherwise, we essentially force all code working on `AffineExpr` to actually work on arbitrary expressions, which defeats the purpose.
Maybe we would need an `Expr` which is used for utility purposes and can be converted to an `AffineExpr`, if it is actually affine.

> One could modify from the "wrong" version to the "right" version in affine exp simplification as well

I agree, but would this still be **affine** expression simplification, i.e. simplification working on an affine expression? Wouldn't it instead be expression simplification, where the result is an affine expression?


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