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

[Mehdi AMINI via Phabricator via llvm-commits]

mehdi_amini added a comment.

In D73826#1878508 <https://reviews.llvm.org/D73826#1878508>, @nicolasvasilache wrote:

> > 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.


I don't see how this patch is getting in this direction though.

If the goal is to write a TensorComprehension specifications for the ops, it seems like you may end-up generating ODS directly from such specifications. In any case, we could discuss this direction, but this is another thing that you didn't bring before.

>> 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?

When we didn't have this feature, we were writing inline C++ in ODS, or adding extra method that were calling C++ implementation.

> 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?

You haven't clarified how this is "slowing down the progress of Linalg" so far. But at the same time "Linalg" is a very fuzzy things for most people...

> 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.

The immediate actionable direction I can provide is the same as before: please start answering questions, and trying to build more consensus behind what you're trying to achieve. I don't think being more and more pushy on this is gonna suddenly enlighten anyone and convince them, at least not me.
So I'll re-ask:

1. It isn't clear what is really blocked here, where is the urgency, especially with respect to current alternatives that I'd like to clarify. You just claimed progress is being blocked without specifics.
2. Jacques' question is a simple yes or no : "Just to be clear, so all of this is so that you can write"

  let input_indexing_maps = [AffineExpressions<["i", "r_j"]>,
                               AffineExpressions<["r_j"]>];
  let output_indexing_maps = [AffineExpressions<["i"]>];
  
  along with the op and from this you are generating
  
  return SmallVector<AffineMap, 4>{AffineMap::get(2, 0, {i, j}),
                                     AffineMap::get(2, 0, {j}),
                                     AffineMap::get(2, 0, {i})};




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73826