There may be some misunderstandings, here. This thread and the PR are not trying to move to a unified matmul (though this is one small step towards that). Here, I’m just performing the cleanup that we are planning for a long time. The removal of these operations has been agreed by those in the discussions and that included you, so maybe a refresh would help.
We first proposed refactoring the matmul operations exactly 1 year ago. That was a long discussion (42 replies, ~1 month), and we agreed to a few steps forward:
- Move the operations out of OpDSL, which was done for matmul, batch_matmul, batch_reduce_matmul.
- Introduction of linalg contract and a new elementwise.
- Remove the conflicting ops, like the old elemwise variants and the transposed variants.
There were other discussions in this topic as well. The explosion of ops in Linalg, following the multiple convolution alternatives being added, culminating with the linalg operation tree proposal. We also had long discussions on both contract and elementwise, all of which you either participated directly, or people in your team did. These were all over the last year, as recent as this month, and all long discussions with many replies and long duration.
So I’m a little surprised when you say:
Now, for the practical side of things, let me try to clarify some points below:
First, let’s focus on the transposed versions, since this thread/PR do not mention the batched versions, nor I have the intention to deprecate them soon.
Here are some findings:
- Torch-MLIR has no mention of the transposed variants, so it should need no changes.
- TOSA is in-tree and does not use the transposed version, no changes needed.
- StableHLO doesn’t seem to use it either.
We’re also discussing the builder methods as specializations, which I’m looking into, as proposed by @qed.
We’re also discussing this on the PR, but here it starts to get fuzzy the upstream / downstream responsibilities. As proposed on the PR, IREE can have those matchers in its own tree, as well as an addition to linalgx for the time being. None of these interim solutions are upstream, but a longer term structured matcher for this cases has been proposed a long time ago by our team when it comes to linalg.generic and op DAG pattern matching.
If this is something that will be beneficial to all upstream, we can start working on it, but this work should not hold the cleanup of Linalg that has been agreed and discussed for a whole year, including heavily with your team.
To be clear, this is not a heavy change at all. And the guide is in the PR already. Once it gets merged, with all the additions we’re discussing in the PR, it will have the necessary tools to let people know how to do that on their downstreams. There is no pass I can create to convert an operation that no longer exists.
There is no deadline, we’re (and here you’re included) changing this very slowly and moving forward. This is one small step in a list of small steps that we’ve been doing together for a whole year. We’ll continue doing these steps, as the community continues to agree (only positive responses so far).
Unlike LLVM IR, MLIR has no deprecation policy because it’s still too young. We’re trying to move into a state where the dialects reach a reasonably stable form to be able to bring a deprecation policy, but right now, this would only slow down progress. That’s why I always include you in the discussions, and why you have been participating on all of them.
Furthermore, we cannot (and should not) have to consider all unknown downstream projects that use MLIR, if they do not participate in the discussions upstream. Whoever has a project based in MLIR should be able to work out for themselves how to move at the upstream speed, as has been the case for LLVM for the last 20 years.