[PATCH] D73826: [mlir][Linalg] Provide a Tablegen backend to specify named Linalg ops declaratively

[Nicolas Vasilache via Phabricator via llvm-commits]

nicolasvasilache added a comment.

> we didn't really get an answer to the questions. I also mentioned

I believe I did answer very clearly :  the objective is to evolve into an einsum-like specification. I’ll paste it here again: a string such as “C(i, j) += A(i, k) * B(k, j)” is enough to specify the linalg.generic configuration for a named matmul op and this generalizes to many ops.

> Where "something like this" is a feature that is generic enough to generalize and be reused across dialects, like D73405 <https://reviews.llvm.org/D73405> :)

And yet we did not wait for having a nice declarative generic assembly form to be able to have Tablegen backed ops, did we?
As everything that has ever been contributed to MLIR, things are done on a per need basis. How is this different?

Now if you happen to have cycles to help with this, I’ll be thrilled! So could you please describe uses of einsum-like notation (or generalizations) for other dialects? Still, does coming up with such examples and a common solution need to slow down the progress of Linalg?

> I don't remember you talking to me (or Jacques) about this 3 months ago

We originally talked about this with Jacques, Lei and River independently for some time, most recently back around Nov, there is an open internal bug that I can reference when I come back from vacation. At the time I don’t remember you being involved or having contributed to Tablegen aspects so it makes sense you may miss context. Note that at the time custom Tablegen backends were explicitly suggested as a solution (this is based on my recollection though so may be a bit fuzzy after all this time :) I’d have to look at the bug for details). Now that I need it for growing the set of Linalg ops, I am trying to male progress. This also happens to be an explicit KR, feel free to look it up internally or I can point you to it when I am back in office.

Bottom line, while I appreciate the objective of being future proof and general, I do not see a justification for blocking on this in this instance, place and time. I think this goes contrary to how MLIR contributors have been making progress: on a per need basis.

If the worry is that mlir-tblgen should not be augmented with DSL specific behavior I agree and I am happy to spin off a Linalg-specific binary that will be NFC for everything else Tablegen.

More generally I think we are touching a broader point: we want to allow and even encourage progress in specialized areas/dialects. When it is time for refactoring and generalization, we will do it, as usual, on a per-need basis. A very good example of this is the OpsInterface, which refactored and reused the Model/Concept you yourself proposed to solve the “inheritance” issue Linalg had in very beginning. This type of iteration takes months and benefits from existing concrete use cases.

Please let me know something actionnable that we can apply to unblock the declarative specification of named Linalg ops.

Thanks @joker-eph!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73826/new/

https://reviews.llvm.org/D73826