[Mlir-commits] [mlir] [MLIR][TilingInterface] Extend consumer fusion for multi-use of producer (PR #110105)

[llvmlistbot at llvm.org]

================
@@ -1481,21 +1481,33 @@ checkAssumptionForFusingConsumer(tensor::InsertSliceOp candidateSliceOp) {
 /// failure otherwise.
 static FailureOr<OpOperand *> getConsumerFromUses(Value val,
                                                   Block *containingOpBlock) {
-  // Step 1. Check that the value has exactly one use.
-  if (!llvm::hasSingleElement(val.getUses()))
-    return failure();
-  // Step 2. Get uses.
-  OpOperand &operand = (*val.getUses().begin());
-  Operation *consumerOp = operand.getOwner();
-  // TODO: We have to init result of consumer before scf.for, use
-  //       DestinationStyleOpInterface to get result shape from init for now.
-  //       Add support for other op such as op has InferTypeOpInterface.
-  if (!isa<TilingInterface>(consumerOp) ||
-      !isa<DestinationStyleOpInterface>(consumerOp))
-    return failure();
-  if (containingOpBlock != consumerOp->getBlock())
-    return failure();
-  return &operand;
+  // Check that the value has exactly one use which isn't a scf.yield or a
+  // tensor.parallel_insert_slice op.
+  Operation *visitedConsumerOp = nullptr;
----------------
Yun-Fly wrote:

> Apologies for adding confusion with "real" - but I hope I've been able to communicate the intention of the PR and how this isn't adding to the complexity (as it isn't aiming to deal with the IR you mentioned).

Thanks for your explanation! I see.

> as the condition is only going to allow scf.yield or tensor.parallel_insert_slice as the other uses of producer. And by the nature of these allowed ops since they're terminator ops, we have a clear path to fusing the consumer and isn't adding to the complexity which might be the case in previous PR?

Yeah, exactly. So it probably sounds better to rename the PR title to _Extend consumer fusion for multi-use of producer **shared by terminator ops**_?

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