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
Differential D103244
[mlir][affine] Fold affine.min with constant zero expressions antiagainst on May 27 2021, 5:19 AM. Authored by
Details Such affine.min ops can be folded into constant zero op, given Depends On D103243
Diff Detail
Event TimelineComment Actions I'm not sure that values of index type cannot be negative. Index are signless, so the interpretation of the most significant bit depends on the operation. Comment Actions https://github.com/llvm/llvmproject/blob/86627be23312bd227e5afa88c206771a9aaf6589/mlir/test/Conversion/AffineToStandard/loweraffine.mlir#L158 relies on having index with negative value, for example, and so does https://github.com/llvm/llvmproject/blob/main/mlir/test/Conversion/StandardToSPIRV/stdopstospirv.mlir#L525. The only restriction on nonnegative values I know is in the RHS of floordiv/ceildiv/mod of affine expressions, but that is not related to the type. Comment Actions 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? Comment Actions I'm not sure we restrict indices to be positive either... If there is an op that clearly requires values to be nonnegative and has undefined behavior otherwise, we could follow a Ccompiler 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:
