[Mlir-commits] [mlir] [mlir][linalg] Convert linalg.named to linalg.elementwise op. (PR #148424)

[Renato Golin]

rengolin wrote:

> Named (linalg.add)
> `\/ categorize-(all) named-ops`
> Category (linalg.contraction)
> `\/ generalize-(all) named-ops /\ categorize (all) generic-ops`
> Generic (linalg.generic)

Awesome, this is similar to what I had in mind. And to be clear, we're just talking strategy, here. This PR is a much simpler thing and good for what it is, we just need to know where in the general strategy it will live, and how to get the naming / conversion right.

My main concerns are on how we represent the various steps:
1. Do we make every `generalization` and `categorization` _step-wise_ and then users have to "iterate until it gets on the level they want"? 
   1. How do we manage the categorization of a DAG where only some ops can go to named ops while others must remain as a category or generic?
   1. What if the DAG is in separate representations? Do we step-wise generalize/categorize individual ops to the next step, or do we find a common stage and convert all to that stage? And is that `max` or `min` of the final stages?
1. Or do we have names to each morphism that relates to the end state (named/category/generic) and convert all to that stage?
   1. What if some ops can't be moved to that form? Is this a soft fail or a hard fail?
   1. What if we want some ops to be at a particular form while others are different? The current `softmax` _lowering_ produces both generic and named ops. Is that a good thing, even?

Alternatively, we can have **both**. So, if you ask for a "generalization morphism", you go step-wise. If you ask for a "morphism into a particular stage", you get a normalization of all ops into that form (generalize and specialize). This may end up being _a lot_ of different patterns, especially for generalization strategies (match all named ops), so we also need care in how we do this.

I'd also make any issues in conversion _soft failures_, and then both _step-wise_ and _into form_ variants would behave similar, and the latter can be just an iteration of the former until all conversions return soft failures.

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