[Mlir-commits] [mlir] [mlir][loops] Add getters for multi dim loop variables in `LoopLikeOpInterface` (PR #94516)

Oleksandr Alex Zinenko llvmlistbot at llvm.org
Fri Jun 7 01:57:49 PDT 2024


================
@@ -2454,27 +2454,25 @@ bool AffineForOp::matchingBoundOperandList() {
 
 SmallVector<Region *> AffineForOp::getLoopRegions() { return {&getRegion()}; }
 
-std::optional<Value> AffineForOp::getSingleInductionVar() {
-  return getInductionVar();
-}
+ValueRange AffineForOp::getInductionVars() { return {getInductionVar()}; }
 
-std::optional<OpFoldResult> AffineForOp::getSingleLowerBound() {
+SmallVector<OpFoldResult> AffineForOp::getMixedLowerBound() {
   if (!hasConstantLowerBound())
-    return std::nullopt;
+    return {};
   OpBuilder b(getContext());
-  return OpFoldResult(b.getI64IntegerAttr(getConstantLowerBound()));
+  return {OpFoldResult(b.getI64IntegerAttr(getConstantLowerBound()))};
 }
----------------
ftynse wrote:

The bound is computed as an (affine) function of multiple values, which are passed as operands to the loop operation. It cannot be represented with one value since the result of that function is not materialized. All existing interface methods are "best effort", i.e., they return non-nullopt value if it makes sense for the specific loop. And should be documented as such if they aren't already. So it is fine to return nullopt for affine loops with non-constant upper bound.

If we _really_ needed that, we could add a `materializeLower/UpperBound(OpBuilder &)` method, but I doubt it's useful.

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


More information about the Mlir-commits mailing list