[all-commits] [llvm/llvm-project] cf6f21: [mlir][tblgen] Generate generic adaptors for Ops
zero9178 via All-commits
all-commits at lists.llvm.org
Wed Jan 11 05:34:24 PST 2023
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: cf6f21751622fcae326d1fe13bc5afd74c4e720f
https://github.com/llvm/llvm-project/commit/cf6f21751622fcae326d1fe13bc5afd74c4e720f
Author: Markus Böck <markus.boeck02 at gmail.com>
Date: 2023-01-11 (Wed, 11 Jan 2023)
Changed paths:
M mlir/include/mlir/TableGen/Class.h
M mlir/include/mlir/TableGen/Operator.h
M mlir/lib/TableGen/Class.cpp
M mlir/lib/TableGen/Operator.cpp
M mlir/test/mlir-tblgen/op-decl-and-defs.td
M mlir/test/mlir-tblgen/op-operand.td
M mlir/tools/mlir-tblgen/OpClass.cpp
M mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
A mlir/unittests/IR/AdaptorTest.cpp
M mlir/unittests/IR/CMakeLists.txt
Log Message:
-----------
[mlir][tblgen] Generate generic adaptors for Ops
This is part of the RFC for a better fold API: https://discourse.llvm.org/t/rfc-a-better-fold-api-using-more-generic-adaptors/67374
This patch implements the generation of generic adaptors through TableGen. These are essentially a generalization of Adaptors, as implemented previously, but instead of indexing into a `mlir::ValueRange`, they may index into any container, regardless of the element type. This allows the use of the convenient getter methods of Adaptors to be reused on ranges that are the result of some kind of mapping functions of an ops operands.
In the case of the fold API in the RFC, this would be `ArrayRef<Attribute>`, which is a mapping of the operands to their possibly-constant values.
Implementation wise, some special care was taken to not cause a compile time regression, nor to break any kind of source compatibility.
For that purpose, the current adaptor class was split into three:
* A generic adaptor base class, within the detail namespace as it is an implementation detail, which implements all APIs independent of the range type used for the operands. This is all the attribute and region related code. Since it is not templated, its implementation does not have to be inline and can be put into the cpp source file
* The actual generic adaptor, which has a template parameter for the range that should be indexed into for retrieving operands. It implements all the getters for operands, as they are dependent on the range type. It publicly inherits from the generic adaptor base class
* A class named as adaptors have been named so far, inheriting from the generic adaptor class with `mlir::ValueRange` as range to index into. It implements the rest of the API, specific to `mlir::ValueRange` adaptors, which have previously been part of the adaptor. This boils down to a constructor from the Op type as well as the verify function.
The last class having the exact same API surface and name as Adaptors did previously leads to full source compatibility.
Differential Revision: https://reviews.llvm.org/D140660
Commit: bbfa7ef16dd9900b36abfa1a5f2faddb81afeb51
https://github.com/llvm/llvm-project/commit/bbfa7ef16dd9900b36abfa1a5f2faddb81afeb51
Author: Markus Böck <markus.boeck02 at gmail.com>
Date: 2023-01-11 (Wed, 11 Jan 2023)
Changed paths:
M mlir/docs/Canonicalization.md
M mlir/docs/DefiningDialects/_index.md
M mlir/docs/Tutorials/Toy/Ch-7.md
M mlir/examples/toy/Ch7/include/toy/Ops.td
M mlir/examples/toy/Ch7/mlir/ToyCombine.cpp
M mlir/include/mlir/IR/DialectBase.td
M mlir/include/mlir/IR/OpDefinition.h
M mlir/include/mlir/TableGen/Dialect.h
M mlir/include/mlir/TableGen/Operator.h
M mlir/lib/TableGen/Dialect.cpp
M mlir/lib/TableGen/Operator.cpp
A mlir/test/IR/test-fold-adaptor.mlir
M mlir/test/lib/Dialect/Test/TestDialect.cpp
M mlir/test/lib/Dialect/Test/TestOps.td
A mlir/test/mlir-tblgen/has-fold-invalid-values.td
M mlir/test/mlir-tblgen/op-decl-and-defs.td
M mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
Log Message:
-----------
[mlir] Add a new fold API using Generic Adaptors
This is part of the RFC for a better fold API: https://discourse.llvm.org/t/rfc-a-better-fold-api-using-more-generic-adaptors/67374
This patch implements the required foldHook changes and the TableGen machinery for generating `fold` method signatures using `FoldAdaptor` for ops, based on the value of `useFoldAPI` of the dialect. It may be one of 2 values, with convenient named constants to create a quasi enum. The new `fold` method will then be generated if `kEmitFoldAdaptorFolder` is used.
Since the new `FoldAdaptor` approach is strictly better than the old signature, part of this patch updates the documentation and all example to encourage use of the new `fold` signature.
Included are also tests exercising the new API, ensuring proper construction of the `FoldAdaptor` and proper generation by TableGen.
Differential Revision: https://reviews.llvm.org/D140886
Compare: https://github.com/llvm/llvm-project/compare/cce49337aa9f...bbfa7ef16dd9
More information about the All-commits
mailing list