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

Lei Zhang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 13 09:19:46 PST 2020


antiagainst added a comment.

In D73826#1873559 <https://reviews.llvm.org/D73826#1873559>, @mehdi_amini wrote:

> In D73826#1865623 <https://reviews.llvm.org/D73826#1865623>, @antiagainst wrote:
>
> > The main value I see with the OpDefinitionGen hook is that it allows one to **automatically** insert traits and methods into the generated C++ op classes. This is preferable when a dialect's ops have **a large variation of potential traits and methods**, and that information is already encoded with other fields in the op definitions
>
>
> There is no disagreement that this may be useful for some cases: but we should strive to improve ODS itself to provide this facilities. I don't think we want dialect author to write Tablegen backends: this defeats the whole point of ODS in my opinion!


Well actually the new impl indeed changes to write a new TableGen backends. :) But I get your idea here. Yup I agree that we should strive to improve ODS itself and avoid dialect author to write TableGen expansion logic as much as possible. So features that apply to any dialect should be factored out and landed into main OpDefinitionGen. But there are cases it's inevitable like the Linalg case showed here: we have custom syntax defined for op definitions only reasonable to Linalg dialect. One can either completely roll its own TableGen backend or hook into OpDefinitionGen to avoid some boilerplate. I would argue the later saves developers' efforts and it's enhancing the functionality of ODS for dialect-specific use cases. :)


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