Such affine.min ops can be folded into constant zero op, given
that affine ops works on the index type, which by definition
cannot be negative.
Depends On D103243
antiagainst on May 27 2021, 5:19 AM.Authored by
https://github.com/llvm/llvm-project/blob/86627be23312bd227e5afa88c206771a9aaf6589/mlir/test/Conversion/AffineToStandard/lower-affine.mlir#L158 relies on having index with negative value, for example, and so does https://github.com/llvm/llvm-project/blob/main/mlir/test/Conversion/StandardToSPIRV/std-ops-to-spirv.mlir#L525.
The only restriction on non-negative values I know is in the RHS of floordiv/ceildiv/mod of affine expressions, but that is not related to the type.
Ah, I think you are right. I just checked the definition for index type; indeed it's just spec'ed as "signless integer whose size is equal to the natural machine word of the target". I was under the wrong impression due to its close relationship with indices/sizes. Thanks for pointing out!! :)
What I'm trying to do is clean up some of the affine.mins that are used as indices/sizes (as shown in the modified test cases), that shouldn't be negative (otherwise I think there is a problem). Do you know what's the proper way to do that?
I'm not sure we restrict indices to be positive either... If there is an op that clearly requires values to be non-negative and has undefined behavior otherwise, we could follow a C-compiler approach and assume the value passed to this op must not be negative in valid programs. This isn't something we usually do in MLIR though, so I would think carefully before introducing such transformations.
A more robust, but possibly less aggressive approach, is to reason about the sets of values that each result of the affine map used in affine.min can take. I see two cases: