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

[Renato Golin]

rengolin wrote:

> The approach that you are taking here makes sense to me, though there should be some deprecation note for the specialised builders for `linalg.matmul` - presumably we don't want to keep them forever?

I'm not particularly worried about the specializations. They do not show up in the linalg docs and they're only constructing a `matmul` with affine maps, so transforms, parsers, etc. will all handle the standard form. We could even leave them longer term as helpers to create the most common variants (could be renamed to avoid confusion), but I think it's generally a good thing to have these helpers.

> Btw, we rely on `linalg.matmul_transpose_a` for SME and as you mention in the summary, "upstream" LG. I also checked in IREE and identified a few minor things, but nothing too concerning. I will report in [iree-org/iree#21349](https://github.com/iree-org/iree/issues/21349).

That was the point of the forum post and this PR: what's the change the downstreams need to make that work.

* Upstream (torch-mlir, stablehlo, etc) seem fine.
* You seemed ok with it, too.
* We don't use the transpose variants and we're now moving even `matmul` to `contract`, that are easier to vectorize for its various forms.
* IREE has some delta, tracked on that issue, which seem minor and we're already working on it.

Like the others before it in the _"linalg 2.0"_ thread, this is a minor change, with minor impact downstream. If we go slowly, we'll have plenty of time to adapt and move on together, in line with the good old battle tested LLVM strategy.

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