[Mlir-commits] [mlir] [mlir][linalg] Extend elementwise (PR #124661)

[llvmlistbot at llvm.org]

MaheshRavishankar wrote:

> My view is that:

> If we choose to move, we need to reduce the boilerplate in the C++ with a common implementation (static local methods, super-class in table-gen, etc).
> If we choose to create a new one, we must have a deadline to remove the old ones, and that needs to be soon (months, not years). We also must agree on an ABI for the enum elements between unary/binary/ternary to avoid future ABI issues.
I personally prefer a move, but I want this to be a consensus.

The characterization is a bit unclear cause both said "move". My initial suggestion for this line of work was to create Linalg Ops V2 while keeping current OpDSL unchanged, and once we know V2 is on par with V1, deprecate V1. The separation would be easier for clients of Linalg to understand. But the consensus was that we just replace the OpDSL ops for `linalg.matmul` , etc. directly. This did seemed to have worked with almost no downstream disruptions (so kudos to that). Since we have decided to do an "in-place" update, I would vote for an move as well, i.e drop elementwise_unary, elementwise_binary, elementwise_ternary ops and just replace them with `elementwise` . IMO the former split didnt make much sense to begin with. 

So TL;DR I would vote for a move to be consistent with what is happening with other ops. To allow downstream users to catch up we should probably give a deprecation notice, and hopefully upload a patch that deprecates the old ops and in favor of the new ones so that this can be used by downstream users to navigate the change.


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