[all-commits] [llvm/llvm-project] a7bfdc: [mlir][Linalg] Handle multi-result operations in E...

[MaheshRavishankar via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a7bfdc23ab3ade54da99f0f59dababe4d71ae75b
      https://github.com/llvm/llvm-project/commit/a7bfdc23ab3ade54da99f0f59dababe4d71ae75b
  Author: Mahesh Ravishankar <ravishankarm at google.com>
  Date:   2022-08-24 (Wed, 24 Aug 2022)

  Changed paths:
    M mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h
    M mlir/lib/Dialect/Linalg/Transforms/ConstantFold.cpp
    M mlir/lib/Dialect/Linalg/Transforms/ElementwiseOpFusion.cpp
    M mlir/test/Dialect/Linalg/fusion-elementwise-ops.mlir
    M mlir/test/Dialect/Linalg/fusion-elementwise-options.mlir
    M mlir/test/Dialect/Linalg/reshape_fusion.mlir
    M mlir/test/lib/Dialect/Linalg/TestLinalgElementwiseFusion.cpp

  Log Message:
  -----------
  [mlir][Linalg] Handle multi-result operations in Elementwise op fusion.

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.

Differential Revision: https://reviews.llvm.org/D132301