[Mlir-commits] [mlir] [MLIR][Linalg] Remove matmul_transpose variants (PR #147961)

[Renato Golin]

rengolin wrote:

> It would be ideal if we had a deprecation path instead of just a switch.

Ack. I tried to gather that in the forum, but people were not paying attention to that, either. :smiley:

Also, this has been discussed for years and the original patch was almost 1 year ago. 

> * Torch-MLIR (and all other "front end dialects" like StableHLO, etc.) will need to be updated to not generate the batch-matmul operations

This should be straightforward. This PR has the recipe: replace `*_matmul_transpose_*` with `matmul` + appropriate affine map. Everything else _just works_. I could help with that, too, if needed.

> * and downstream compilers (like IREE) need to make sure that they can navigate away from this.

This is less straightforward. From the discussion back then, I had assumed we would all work towards not using it internally, so that we could easily switch later. This is 1 year later. :frowning_face: 

> In LLVM this would be something that would be deprecated on one release and removed on the next release (it is pretty much a break the world change). I dont think all the front end dialect folks are paying attention to this.

Not exactly. We have [backwards compatibility for LLVM IR](https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility), and the support policy describes how to [deprecate entire components](https://llvm.org/docs/SupportPolicy.html#steps-for-removal), but those points apply. We neither have backwards compatibility guarantees for MLIR, nor we're talking about removing an entire dialect. Changes in dialect operations occur more often, and to be honest, this one is already turning 1 year old. I have just removed some old element-wise operations and it didn't _break the world_.

I'm assuming IREE isn't really using releases, here, so talking about releases doesn't make a lot of sense. But that doesn't mean we can be careless when removing stuff, it just means we can do _best effort_ on a case by case basis. We also need to balance upstream versus downstream needs, where the latter cannot impose hard constraints on the former, but can suggest time-frames and ways around.

My proposal is to fix `torch-mlir` to stop emitting `matmul_transpose_*` and understand what are the implications inside IREE (and any other linalg user that still relies on those operations). If IREE can be fixed quickly, we wait. If not, IREE can duplicate those ops inside `linalgx` and deprecate on your own speed.

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