[Mlir-commits] [mlir] [mlir][python] fix up affine for (PR #74495)

[Oleksandr Alex Zinenko]

================
@@ -45,23 +46,50 @@ def __init__(
         - `lower_bound_operands` is the list of arguments to substitute the dimensions,
           then symbols in the `lower_bound` affine map, in an increasing order
         - `upper_bound_operands` is the list of arguments to substitute the dimensions,
-          then symbols in the `upper_bound` affine map, in an increasing order
+          then symbols in the `upper_bound` affine map, in an increasing order.
         """
 
+        if lower_bound_operands is None:
+            lower_bound_operands = []
+        if upper_bound_operands is None:
+            upper_bound_operands = []
+
+        if step is None:
+            step = 1
+        if upper_bound is None:
+            upper_bound, lower_bound = lower_bound, 0
+
+        if isinstance(lower_bound, int):
+            lower_bound = AffineMap.get_constant(lower_bound)
+        elif isinstance(lower_bound, (Operation, OpView, Value)):
+            if len(lower_bound_operands):
+                raise ValueError(
+                    f"Either a concrete lower bound or an AffineMap in combination "
+                    f"with lower bound operands, but not both, is supported."
+                )
+            lower_bound_operands.append(lower_bound)
+            lower_bound = AffineMap.get_identity(1)
----------------
ftynse wrote:

There's no guarantee that `lower_bound` is a single value here. It may be an `OpView` of a multi-result op, at which point a rank-1 identity map would not be correct and I don't even know what happens when a list of lists of values gets passed to `lowerBoundOperands` in the base class init. I'd just check that, if `lower_bound` is an `Operation` or `OpView`, it has a single result. Affine map with rank > 1 will be interpreted as `max` of values and that would feel surprising when reading `affine.ForOp(otherOp)`.

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