[Mlir-commits] [mlir] [mlir][linalg] Extend `FuseElementwiseOps` pattern to work with named ops (PR #144922)

[llvmlistbot at llvm.org]

MaheshRavishankar wrote:

> @rengolin just a bit more info
> 
> [This](https://github.com/llvm/llvm-project/blob/1e2ed8a5861a304d42214fc48c1fa1b9211b3540/mlir/lib/Dialect/Linalg/Transforms/ElementwiseOpFusion.cpp#L159) imposes that the producer is elementwise. But [here](https://github.com/llvm/llvm-project/blob/1e2ed8a5861a304d42214fc48c1fa1b9211b3540/mlir/lib/Dialect/Linalg/Transforms/ElementwiseOpFusion.cpp#L159) they allow consumers to have reductions.

Both the links are the same. Did you intend that?

>. Maybe to start i could just modify the controlFn for linalg-fuse-elementwise-ops pass specifically to only allow linalg.generic. This would keep the current behavior for now, while also giving people more options with the pattern, so everyone would win. Then we can have more time think about if linalg-fuse-elementwise-ops should change.

That might not be enough. For the most part, I think of passes like `linalg-fuse-elementwise-ops` as mostly legacy. I think a lot of users use the `fuseElementwiseOps` method directly, and making it handle named ops is an unexpected change since the fusion now will also generalize while doing a fusion. 

The best way forward might be to add a new method `fuseNamedOpsAsElementwiseOps` and make the core implementation templatized. This way the original method stays as is and only works on generic ops. And the new methods work on named ops + generic ops.

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