[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