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

[Renato Golin]

rengolin wrote:

> > * What's the benefit of lumping these ops under just one op? That is, is there a benefit to lumping arities?
> 
> On a single op, the enum business is complicated. Bit-field-like encoding helps clean up a bit, but it's still ugly. I'd rather see three ops (unary, binary, ternary), but again, that's my personal preference. If there's consensus on a single one, I'm also happy to acquiesce.

After speaking with a few people about this, here's my understanding.

### Move `elemwise_unary` / `elemwise_binary`

#### Pros
* Clean cut. No new (temporary) ops initially, no old (deprecated) later
* Simply move to ODS + affine maps, which is a practice we have agreed for other ops

#### Cons
* More boilerplate in TableGen / C++, though the C++ part can be commoned up
* Potential churn on current users, though we had little to none on `matmuls`

### Create `element_wise`, move, deprecate `elemwise_unary` / `elemwise_binary`

#### Pros
* Single implementation reduces boilerplate in TableGen / C++
* Less churn on current users, have time to move at their pace

#### Cons
* Yet another operation that does the same thing as previous others
* Enum business for unary/binary/ternary isn't trivial (future ABI issues?)
* Users may _"never find the time to move"_ and we'll have duplicated ops for a long time

### Analisys

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).

I personally prefer a move, but I want this to be a consensus.

@rolfmorel @shahidact @banach-space @ftynse @MaheshRavishankar @qedawkins 

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