[Mlir-commits] [mlir] [Linalg] Update Conv Decomposition patterns to work with generic convolution ops as well (PR #174196)

[Han-Chung Wang]

hanhanW wrote:

> > From my perspective, **Specialization** is conceptually a pre-processing step that should be applied before transformations like **Decomposition** or **Vectorization**, rather than being embedded inside them. This doesn't affect my usage and I won't be blocking this change. However, I would be great to hear from e.g. @rengolin who recently contributed [Interchangeability of Forms](https://mlir.llvm.org/docs/Rationale/RationaleLinalgDialect/#interchangeability-of-formsa-nameformsa) to our docs.
> 
> I would propose we postpone this discussion, because there are still many rewrite patterns that work in generic / named ops that people rely on, and we haven't yet decided what do we do with the various normal forms in Linalg.
> 
> I am writing a [document](https://docs.google.com/document/d/1yyJ5djkosjHoziqpm-y6z1CA2A8rxvyGXi6ckU6AVvk/edit?usp=sharing) that discusses those things from the point of view of canonicalization. It's not complete yet, and has more questions than answers for the normal forms (but more answers than questions for the general canonical form, I'd hope).
> 
> But I think this is the PoV that we need to look at specialization / generalization: they're normal forms, but not canonical forms. We first need to define if we want them as co-canonical (where your argument stands), or not (where we'd rewrite a lot of code to match the new vision of what's canonical, when and where.

To be clear, this is not about generailzation or specialization. This is a PR that extends the existing patterns to handle conv decompisition in generic form. It is a pure improvement for these patterns. My claim is that upstream patterns provide transformations and downstream users build the passes with the patterns. Does adding a control function to keep the same behavior sound better? It is a little weird to me though, because new users would be confused about why the default behavior is filtering out conv ops in generic op form. If it were me, I'd apply it to all the ops that meet requirement, and have a note in PR description about how to restore to the old behavior. What do you think?

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