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

Nicolas Vasilache via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 14 14:20:54 PST 2020


nicolasvasilache added a comment.

@jpienaar and @mehdi_amini thanks for your fast turnaround on this!

Ultimately, my objective still is and has always been to write many DSL ops as a `linalg.generic` with some variant of Einsum/TC notation:  e.g. `A(i, r_j) * B(r_j) -> C(i)` and have ops be automatically generated from this almost mathematical form.
We have had quite some experience in that area and I claim it is a fundamentally "good thing to have".
Once that exists, it can be pattern-matched to library calls automatically + resist transformations such as tiling and fusion since we have all the IR in place to do that.

This revision is a baby step that wants to act as a forcing function on a topic that seems to be, well.. , interesting: it is good to hear the objections clearly as to where Tablegen-based infrastructure is allowed to evolve.

Is there a world in which we can have such an Einsum-based parser on textual format to specify Linalg ops?
Does this have to be a language outside of MLIR? (I would certainly hope not).
I think https://reviews.llvm.org/D73405 sets a nice precedent and I would very much want to see something like this for specifying Linalg ops declaratively.

If this Einsum-based parser + Linalg Tablegen backend will never be acceptable future, I would love to understand why not and what alternatives people would recommend.

Thanks for your insights!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73826





More information about the llvm-commits mailing list