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

[Javed Absar]

javedabsar1 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?
> >    2. 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?
> > 2. 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?
> >    2. 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.

> > 1. Do we make every `generalization` and `categorization` _step-wise_
`-linalg-morph-ops=options`
The options are -
- `generalize-named-ops` (exactly as legacy --linalg-generalize-named-ops, which converts named to generic
- `generalize-all-ops`  named + category ops
- `categorize-named-ops`  rewrite patterns from this PR for elementwise and new ones for contraction etc.
We can iterate over exact name. The options pack populate*Pattern so its not a headache.

> >   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?
`-linalg-morph-ops=categorize{...}`


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