[Mlir-commits] [mlir] [mlir][Canonicalize] Copy ParallelOp Attributes in Single-iteration (PR #145852)

[Mehdi Amini]

================
@@ -3133,6 +3133,16 @@ struct ParallelOpSingleOrZeroIterationDimsFolder
                                     newSteps, op.getInitVals(), nullptr);
     // Erase the empty block that was inserted by the builder.
     rewriter.eraseBlock(newOp.getBody());
+
+    // The new ParallelOp needs to keep all attributes from the old one, except
+    // for "operandSegmentSizes" which will be outdated.
+    for (const auto &namedAttr : op->getAttrs()) {
+      if (namedAttr.getName() == ParallelOp::getOperandSegmentSizeAttr())
+        continue;
+      rewriter.modifyOpInPlace(newOp, [&]() {
+        newOp->setAttr(namedAttr.getName(), namedAttr.getValue());
+      });
+    }
----------------
joker-eph wrote:

> Sure its discardable, but it can also propagate it. It doesnt know/doesnt care. If the attribute is not valid anymore, then that is the problem of something that is adding the attribute downstream. I think it is a pragmatic solution to keep the attributes here without any gaurantee that the attribute semantics are preserved on the rewrite.

I already explained to you why this is incorrect, I won't get into it again, please refer to past discussions.

> And why would it round trip through the uniquer? It isnt creating a new attribute, just transfering it. It should be cheap.

This is iterating through the dictionary of attributes of the original op, and for each of them it'll call `newOp->setAttr()`. This means that for each attribute it will take the existing incrementally built dictionary on the new op, unpack it to a list of NamedAttribute, append the new NamedAttribute, and build a new dictionary through the uniquer: as many times as there are attributes to be added.

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