| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][irdl] Add irdl.attributes operation for defining named attributes This commit introduces the irdl.attributes operation, which allows defining named attributes for the parent operation. Each attribute is defined with a name and a type constraint. Example usage: irdl.dialect @example { irdl.operation @attr_op { %0 = irdl.any %1 = irdl.is i64 irdl.attributes { "attr1" = %0, "attr2" = %1 } } } In this example the operation will expect an arbitrary attribute "attr1" and an attribute "attr2" with value i64. Reviewed By: math-fehr, Mogball Differential Revision: https://reviews.llvm.org/D152618 | 3 年前 | |
[mlir][irdl] Introduce names in IRDL value lists (#123525) In order to meaningfully generate getters and setters from IRDL, it makes sense to embed the names of operands, results, etc. in the IR definition. This PR introduces this feature. Names are constrained similarly to TableGen names. | 1 年前 | |
[mlir][irdl] Introduce names in IRDL value lists (#123525) In order to meaningfully generate getters and setters from IRDL, it makes sense to embed the names of operands, results, etc. in the IR definition. This PR introduces this feature. Names are constrained similarly to TableGen names. | 1 年前 | |
[mlir][irdl] Introduce names in IRDL value lists (#123525) In order to meaningfully generate getters and setters from IRDL, it makes sense to embed the names of operands, results, etc. in the IR definition. This PR introduces this feature. Names are constrained similarly to TableGen names. | 1 年前 | |
[mlir][irdl] Add irdl.any_of operation The irdl.any_of operation represent a constraint that is satisfied if any of its subconstraint is satisfied. For instance, in the following example: %0 = irdl.is f32 %1 = irdl.is f64 %2 = irdl.any_of(f32, f64) %2 can only be satisfied by f32 or f64. Note that the verification algorithm required by irdl.any_of is non-trivial, since we want that the order of arguments of irdl.any_of to not matter. For this reason, our registration algorithm fails if two constraints used by any_of might be satisfied by the same Attribute. This is approximated by checking the possible Attribute bases of each constraints. Depends on D145734 Reviewed By: Mogball Differential Revision: https://reviews.llvm.org/D145735 | 3 年前 | |
[MLIR][IRDL] Added IRDL to C++ Translation (#141248) This PR introduces a new tool, mlir-irdl-to-cpp, that converts IRDL to C++ definitions. The C++ definitions allow use of the IRDL-defined dialect in MLIR C++ infrastructure, enabling the use of conversion patterns with IRDL dialects for example. This PR also adds CMake utilities to easily integrate the IRDL dialects into MLIR projects. Note that most IRDL features are not supported. In general, we are only able to define simple types and operations. - The only type constraint supported is irdl.any. - Variadic operands and results are not supported. - Verifiers for the IRDL constraints are not generated. - Attributes are not supported. --------- Co-authored-by: Théo Degioanni <theo.degioanni.llvm.deluge062@simplelogin.fr> Co-authored-by: Fehr Mathieu <mathieu.fehr@gmail.com> | 1 年前 | |
[MLIR][IRDL] Added IRDL to C++ Translation (#141248) This PR introduces a new tool, mlir-irdl-to-cpp, that converts IRDL to C++ definitions. The C++ definitions allow use of the IRDL-defined dialect in MLIR C++ infrastructure, enabling the use of conversion patterns with IRDL dialects for example. This PR also adds CMake utilities to easily integrate the IRDL dialects into MLIR projects. Note that most IRDL features are not supported. In general, we are only able to define simple types and operations. - The only type constraint supported is irdl.any. - Variadic operands and results are not supported. - Verifiers for the IRDL constraints are not generated. - Attributes are not supported. --------- Co-authored-by: Théo Degioanni <theo.degioanni.llvm.deluge062@simplelogin.fr> Co-authored-by: Fehr Mathieu <mathieu.fehr@gmail.com> | 1 年前 | |
[MLIR][IRDL] Added IRDL to C++ Translation (#141248) This PR introduces a new tool, mlir-irdl-to-cpp, that converts IRDL to C++ definitions. The C++ definitions allow use of the IRDL-defined dialect in MLIR C++ infrastructure, enabling the use of conversion patterns with IRDL dialects for example. This PR also adds CMake utilities to easily integrate the IRDL dialects into MLIR projects. Note that most IRDL features are not supported. In general, we are only able to define simple types and operations. - The only type constraint supported is irdl.any. - Variadic operands and results are not supported. - Verifiers for the IRDL constraints are not generated. - Attributes are not supported. --------- Co-authored-by: Théo Degioanni <theo.degioanni.llvm.deluge062@simplelogin.fr> Co-authored-by: Fehr Mathieu <mathieu.fehr@gmail.com> | 1 年前 | |
[mlir][irdl] Add IRDL registration This patch add support for loading IRDL dialects at runtime with mlir-opt. Given the following dialect.irdl file: mlir module { irdl.dialect @cmath { irdl.type @complex { %0 = irdl.is f32 %1 = irdl.is f64 %2 = irdl.any_of(%0, %1) irdl.parameters(%2) } irdl.operation @norm { %0 = irdl.any %1 = irdl.parametric @complex<%0> irdl.operands(%1) irdl.results(%0) } } the IRDL file can be loaded with the mlir-opt --irdl-file=dialect.irdl command, and the following file can then be parsed: mlir func.func @conorm(%p: !cmath.complex<f32>, %q: !cmath.complex<f32>) -> f32 { %norm_p = "cmath.norm"(%p) : (!cmath.complex<f32>) -> f32 %norm_q = "cmath.norm"(%q) : (!cmath.complex<f32>) -> f32 %pq = arith.mulf %norm_p, %norm_q : f32 return %pq : f32 } To minimize the size of this patch, the operation, attribute, and type verifier are all always returning success(). Depends on D144692 Reviewed By: rriddle, Mogball, mehdi_amini Differential Revision: https://reviews.llvm.org/D144693 | 3 年前 | |
[mlir][irdl] Introduce names in IRDL value lists (#123525) In order to meaningfully generate getters and setters from IRDL, it makes sense to embed the names of operands, results, etc. in the IR definition. This PR introduces this feature. Names are constrained similarly to TableGen names. | 1 年前 | |
[mlir][irdl] Add irdl.any_of operation The irdl.any_of operation represent a constraint that is satisfied if any of its subconstraint is satisfied. For instance, in the following example: %0 = irdl.is f32 %1 = irdl.is f64 %2 = irdl.any_of(f32, f64) %2 can only be satisfied by f32 or f64. Note that the verification algorithm required by irdl.any_of is non-trivial, since we want that the order of arguments of irdl.any_of to not matter. For this reason, our registration algorithm fails if two constraints used by any_of might be satisfied by the same Attribute. This is approximated by checking the possible Attribute bases of each constraints. Depends on D145734 Reviewed By: Mogball Differential Revision: https://reviews.llvm.org/D145735 | 3 年前 | |
[mlir][irdl] Introduce names in IRDL value lists (#123525) In order to meaningfully generate getters and setters from IRDL, it makes sense to embed the names of operands, results, etc. in the IR definition. This PR introduces this feature. Names are constrained similarly to TableGen names. | 1 年前 | |
[mlir][irdl] Add irdl.base op (#76400) The irdl.base op represent an attribute constraint that will check that the base of a type or attribute is the expected one (e.g. IntegerType) . Example: mlir irdl.dialect @cmath { irdl.type @complex { %0 = irdl.base "!builtin.integer" irdl.parameters(%0) } irdl.type @complex_wrapper { %0 = irdl.base @complex irdl.parameters(%0) } } The above program defines a cmath.complex type that expects a single parameter, which is a type with base name builtin.integer, which is the name of an IntegerType type. It also defines a cmath.complex_wrapper type that expects a single parameter, which is a type of base type cmath.complex. | 2 年前 | |
[mlir][irdl] Introduce names in IRDL value lists (#123525) In order to meaningfully generate getters and setters from IRDL, it makes sense to embed the names of operands, results, etc. in the IR definition. This PR introduces this feature. Names are constrained similarly to TableGen names. | 1 年前 | |
[mlir][irdl] Introduce names in IRDL value lists (#123525) In order to meaningfully generate getters and setters from IRDL, it makes sense to embed the names of operands, results, etc. in the IR definition. This PR introduces this feature. Names are constrained similarly to TableGen names. | 1 年前 | |
[MLIR][IRDL] Support camelCase segment size attributes in IRDL verifier (#168836) Two years ago, operand_segment_sizes and result_segment_sizes were renamed to operandSegmentSizes and resultSegmentSizes (check related commits, e.g. https://github.com/llvm/llvm-project/commit/363b655920c49a4bcb0869f820ed40aac834eebd). However, the op verifiers in IRDL loading phase is still using old attributes like operand_segment_sizes and result_segment_sizes, which causes some conflict, e.g. it is not compatible with the OpView builder in MLIR python bindings (which generates camelCase segment attributes). This PR is to support to use camelCase segment size attributes in IRDL verifier. Note that support of operand_segment_sizes and result_segment_sizes is dropped. I found this issue since I'm working on a new IRDL wrapper in the MLIR python bindings. | 8 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 |