This is an archive of the discontinued LLVM Phabricator instance.

[mlir][Linalg] Handle multi-result operations in Elementwise op fusion.
ClosedPublic

Authored by mravishankar on Aug 20 2022, 8:41 AM.

Details

Summary

This drops the artificial requirement of producers having a single
result value to be able to fuse with consumers.

The current default also only fuses producer with consumer when the
producer has a single use. This is a simplifying assumption. There are
legitimate use cases where a producer can be fused with consumer and
the fused o pcould be used to replace the uses of the producer as
well. This needs to be done with care to avoid use-def violations. To
allow for downstream users to explore more fusion opportunities, the
core transformation method is exposed as a utility function.

This patch also modifies the control function to take just the fused
operand as the argument. This is enough information for the callers to
get the producer and the consumer operations being considered to
fuse. It also provides information of which producer result is used.

Diff Detail

Event Timeline

mravishankar created this revision.Aug 20 2022, 8:41 AM
mravishankar requested review of this revision.Aug 20 2022, 8:41 AM

Handle multiple result ops in fusion with reshape.

Expose the method to check if ops are fusable.

Move controlFn out of the fuseElementwiseOps function.

antiagainst accepted this revision.Aug 23 2022, 10:59 AM

Cool stuff!

This revision is now accepted and ready to land.Aug 23 2022, 10:59 AM
hanchung accepted this revision.EditedAug 23 2022, 11:27 AM

LGTM, just few nits

mlir/lib/Dialect/Linalg/Transforms/ConstantFold.cpp
124–128

I think we can rewrite it with iterating through getInputOperands() method. It's cleaner to me. E.g.,

for (auto operand: genericOp.getInputOperands()) {
  if (...)
    return failure();
}
mlir/lib/Dialect/Linalg/Transforms/ElementwiseOpFusion.cpp
175–177

It's already checked in areElementwiseOpsFusable. Since this is an implementation detail, we can assume that it meets the requirements. (or maybe put assert(areElementwiseOpsFusable(fusedOperand) in the beginning.)

244–245

Do we want to check if the results of producers are used by others? Or we rely on canonicalization pattern to remove it if they are unused?

263–265

This is a dup check. We already have the assert in areElementwiseOpsFusable.

874

nit: auto. dyn_cast already describes the type.

892–912

nit: add braces for the if-condition. Let's keep the consistency like above checks.

mravishankar marked 3 inline comments as done.

Address comments.

This revision was landed with ongoing or failed builds.Aug 23 2022, 10:57 PM
This revision was automatically updated to reflect the committed changes.