[Mlir-commits] [mlir] [mlir] Restore fullyComposeAffineMapAndOperands in simplifyConstrainedMinMaxOp (PR #233743)

llvmlistbot at llvm.org llvmlistbot at llvm.org
Tue Oct 20 01:31:39 PDT 2026


https://github.com/xshang-synaptics created https://github.com/llvm/llvm-project/pull/233743

Commit d725513e7d92 (#189246, fixing #127436) hardened simplifyConstrainedMinMaxOp against null operand values. As a side effect of that refactor it dropped the operand composition:

    -  SmallVector<Value> operands = ...getOperands();
    -  affine::fullyComposeAffineMapAndOperands(&map, &operands);
    +  ValueRange operands = op->getOperands();

Without the composition, the constraint solver can no longer fold nested affine.min/max chains whose operands are themselves affine min/max/apply results (they become opaque dims it cannot reason through). A boundary clamp like min(N - offset, size) then stays symbolic even when the enclosing loop bounds make it provably constant. Direct callers of this utility (e.g. IREE's FoldAffineMinInDistributedLoops) do not run affine canonicalization beforehand, so the uncomposed operands leak through and the simplification silently fails.

Restore the composition while keeping the #127436 null-operand handling (that block guards the appended internal constraint dims, which are null-valued in either formulation and is a genuine UB fix we must not regress).

>From 0a7406c01f917d3f762583b8dc8541cf820f2d44 Mon Sep 17 00:00:00 2001
From: "Xiaomei.Shang" <Xiaomei.Shang at synaptics.com>
Date: Tue, 20 Oct 2026 01:19:53 -0700
Subject: [PATCH] [mlir] Restore fullyComposeAffineMapAndOperands in
 simplifyConstrainedMinMaxOp

Commit d725513e7d92 (#189246, fixing #127436) hardened
simplifyConstrainedMinMaxOp against null operand values. As a side
effect of that refactor it dropped the operand composition:

    -  SmallVector<Value> operands = ...getOperands();
    -  affine::fullyComposeAffineMapAndOperands(&map, &operands);
    +  ValueRange operands = op->getOperands();

Without the composition, the constraint solver can no longer fold
nested affine.min/max chains whose operands are themselves affine
min/max/apply results (they become opaque dims it cannot reason
through). A boundary clamp like min(N - offset, size) then stays
symbolic even when the enclosing loop bounds make it provably
constant. Direct callers of this utility (e.g. IREE's
FoldAffineMinInDistributedLoops) do not run affine canonicalization
beforehand, so the uncomposed operands leak through and the
simplification silently fails.

Restore the composition while keeping the #127436 null-operand
handling (that block guards the appended internal constraint dims,
which are null-valued in either formulation and is a genuine UB fix
we must not regress).
---
 mlir/lib/Dialect/Affine/Analysis/Utils.cpp | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mlir/lib/Dialect/Affine/Analysis/Utils.cpp b/mlir/lib/Dialect/Affine/Analysis/Utils.cpp
index 0e036dfedbf52e..6bfa5929705b64 100644
--- a/mlir/lib/Dialect/Affine/Analysis/Utils.cpp
+++ b/mlir/lib/Dialect/Affine/Analysis/Utils.cpp
@@ -2318,7 +2318,10 @@ FailureOr<AffineValueMap> mlir::affine::simplifyConstrainedMinMaxOp(
   Builder builder(ctx);
   AffineMap map =
       isMin ? cast<AffineMinOp>(op).getMap() : cast<AffineMaxOp>(op).getMap();
-  ValueRange operands = op->getOperands();
+  SmallVector<Value> operands =
+      isMin ? cast<AffineMinOp>(op).getOperands()
+            : cast<AffineMaxOp>(op).getOperands();
+  affine::fullyComposeAffineMapAndOperands(&map, &operands);
   unsigned numResults = map.getNumResults();
 
   // Add a few extra dimensions.



More information about the Mlir-commits mailing list