[RFC]: Extend Linalg elemwise named ops semantics

[srcarroll]

@rengolin

The amount of "not quite"s in your response clearly illustrates the issues we’re having.

Lol, got it.

@rengolin

But before we start implementing them all, we need to get the minimum set of operations and deprecate the rest.

yah makes sense

@rengolin

If we reduce the commonality argument to the maxium, we’re back with just generic. There would be no reason to have anything else. For a while, this was the truth behind linalg.

But pattern matchers need to do a lot of work to separate the multiple “types” of generic ops, and “linalg is a transform dialect”, ie. the core purpose of this dialect is to be “easy to transform”. If it’s hard to pattern match, then it’s also hard to transform.

I totally agree with this. I’m definitely a big fan of named ops. But yes they should also be kept at a minimum. And I do appreciate that it’s a bit tricky to get a good balance for this.

@rengolin

Makes sense?

Yes I think I follow most of your reasoning here and I appreciate all the details. I would like to keep track of this effort and perhaps even help if I can. Is there another larger scoped thread for this going on?

Thanks again for the response and for putting in effort to improve linalg. I’ve been thinking it was sorely needed for a while, but didn’t have the bandwidth, connections, or intelligence to start anything myself. I did start trying to come up with a better way to represent convolutions a while back, because I was sick of all the named variants that currently exist. But no one cared at the time so I stopped caring myself (and haven’t needed to deal with convolutions in a while). If you’re curious [mlir][linalg] Implement `LinalgGroupedConvolutionOpInterface` to unify grouped convs by srcarroll · Pull Request #94796 · llvm/llvm-project · GitHub