[Mlir-commits] [mlir] [mlir][linalg] Convert linalg.named to linalg.elementwise op. (PR #148424)

[Renato Golin]

rengolin wrote:

> * named -->generic : already exists ( `mlir-opt --linalg-generalize-named-ops` ).

Yes, but it goes straight to generic, can't stop at the middle ops (`contract`, `elementwise`).

> * named -->  linalg.element_wise , linalg.contraction :  This PR `mlir-opt -linalg-named-to-elementwise`. We can rename it to cover contraction-op etc and extend the implementation etc. (`-linalg-named-to-category-ops`?)

Yes, but it's yet-another pass that users can easily miss. There's no "structure" in these passes.

> * new ops elementwise/contraction --> named ops:  Do we want this? I don't see a use case at least to me.

I don't particularly need it, but since there's named-to-TOSA conversions and not from the more general forms, this _may_ be useful. But we don't generally implement what _may_ be useful, so I'd wait for a real user to do this. Again, better if it's part of a _structured conversion_.

> * generic --> named : exists -linalg-specialize-generic-ops  I did some work on this previously as you know but in general this path is not always possible (fused, handwritten generic).

Yes, but it goes straight to generic, can't stop at the middle ops (`contract`, `elementwise`).

> * generic --> elementwise/contract - I think this falls under specialize.

I think this is the most valuable of the bunch. In our cases, at least, it's a lot easier to _match_ against `elementwise`/`contract` than `generic`, and many named patterns will need a DAG to represent the same things and we don't (yet) have a good structured matcher. It's also a lot easier to _transform_ a `contract` into another (different) contract by just operating on affine maps and iterator types than knowing the particularities of `batch_matmul` or `batch_reduce_matmul` and their particular usages.

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