[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#1877588 <https://reviews.llvm.org/D73826#1877588>, @mehdi_amini wrote:

> > 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 don't understand how these two questions can go together as they seem entirely disconnected to me, so I'm probably not understanding the questions in the first place :)
>
> > 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.
>
> The main reason I have been reluctant to move on here is exactly because I would very much want to see something like this for specifying Linalg ops declaratively!
>  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>  :)




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

> In D73826#1877588 <https://reviews.llvm.org/D73826#1877588>, @mehdi_amini wrote:
>
> > > 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 don't understand how these two questions can go together as they seem entirely disconnected to me, so I'm probably not understanding the questions in the first place :)
> >
> > > 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.
> >
> > The main reason I have been reluctant to move on here is exactly because I would very much want to see something like this for specifying Linalg ops declaratively!
> >  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>  :)
>
>
> Ok so if we agree on the principle I think this is a great start then.
>  My main concern is a cost benefit tradeoff: I am super interested in the result of this but do not have the background or resources to do it in a way that is portable and reusable across dialects. It still took me an inordinate amount of time to get to what you see here: this is not my area of expertise.
>  However I did start talking about this to various folks more than 3 months ago but everyone is very busy and it has reached a point where it is blocking.


Fair enough. 
Even though:

- I don't remember you talking to me (or Jacques) about this 3 months ago (the first time this was mentioned was when Lei pushed the Tablegen hook and you mentioned you would use it later, but there was no detail at that time, and it was last month I believe).
- It isn't clear what is really blocked here. We tried to ask before:

> 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})};

But we didn't really get an answer to the questions. I also mentioned "That means there is a tradeoff and we'd like to make sure we consider and weigh a bit more the alternatives, including having something a bit more ugly in ODS if it avoid custom backends. Hence the current question in the diff to try to do this."

> Is it acceptable to move this in a new binary say ‘linalg-named-opgen-dontlookhowugly-pleasehelpimprove” so I am not blocked. When the right people have cycles and they see the end result they can start lending a hand.

It may be, but I'd be more comfortable supporting this if you could first help us figuring out the answers to the questions asked a few days ago. I'm still not sure I got the complete picture about the urgency (what is blocked exactly? why is it important right now?) and the alternatives.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73826