maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/mlir/test/mlir-tblgen/op-result.td

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

127 lines
5.0 KiB
TableGen
Raw Normal View History

[TableGen] Generate op declaration and definition into different files Previously we emit both op declaration and definition into one file and include it in *Ops.h. That pulls in lots of implementation details in the header file and we cannot hide symbols local to implementation. This CL splits them to provide a cleaner interface. The way how we define custom builders in TableGen is changed accordingly because now we need to distinguish signatures and implementation logic. Some custom builders with complicated logic now can be moved to be implemented in .cpp entirely. PiperOrigin-RevId: 239509594
2019-03-21 08:25:34 +08:00
// RUN: mlir-tblgen -gen-op-defs -I %S/../../include %s | FileCheck %s
[TableGen] Use result names in build() methods if possible This will make it clear which result's type we are expecting in the build() signature. PiperOrigin-RevId: 235925706
2019-02-28 00:40:07 +08:00
Use consistent names for dialect op source files This CL changes dialect op source files (.h, .cpp, .td) to follow the following convention: <full-dialect-name>/<dialect-namespace>Ops.{h|cpp|td} Builtin and standard dialects are specially treated, though. Both of them do not have dialect namespace; the former is still named as BuiltinOps.* and the latter is named as Ops.*. Purely mechanical. NFC. PiperOrigin-RevId: 236371358
2019-03-02 05:48:24 +08:00
include "mlir/IR/OpBase.td"
[ods] Update Operator to record Arg->[Attr|Operand]Index mapping Also fixed bug in type inferface generator to address bug where operands and attributes are interleaved. Differential Revision: https://reviews.llvm.org/D82819
2020-06-30 07:40:52 +08:00
include "mlir/Interfaces/InferTypeOpInterface.td"
[TableGen] Use result names in build() methods if possible This will make it clear which result's type we are expecting in the build() signature. PiperOrigin-RevId: 235925706
2019-02-28 00:40:07 +08:00
Add Dialect in op definition to capture prefix and documentation. Enables specifying the documentation for dialect along with defining the ops of the dialect. The doc generator will be expanded in follow up to emit the documentation in the autogenerated files. This is precursor to allowing common base for all ops in a dialect. All the dialect documentation is super sparse and just added as placeholder. I was tempted (and started) to move ConstantOp to be generated too, but this will be easier post adding extra_methods, so deferring until then. -- PiperOrigin-RevId: 245759984
2019-04-30 00:24:09 +08:00
def Test_Dialect : Dialect {
let name = "test";
}
class NS_Op<string mnemonic, list<OpTrait> traits> :
Op<Test_Dialect, mnemonic, traits>;
def OpA : NS_Op<"one_normal_result_op", []> {
[TableGen] Emit verification code for op results They can be verified using the same logic as operands. PiperOrigin-RevId: 237101461
2019-03-07 04:50:01 +08:00
let results = (outs I32:$result);
}
[TableGen] Support multiple variadic operands/results Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
2019-04-26 05:45:37 +08:00
// CHECK-LABEL: void OpA::build
[MLIR] Change default builders generated by TableGen to use TypeRange for result types - Change the default builders to use TypeRange instead of ArrayRef<Type> - Custom builders defined in LinalgStructuredOps now conflict with the default separate param ones, but the default collective params one is still needed. Resolve this by replicating the collective param builder as a custom builder and skipping the generation of default builders for these ops. Differential Revision: https://reviews.llvm.org/D87926
2020-09-23 11:58:30 +08:00
// CHECK: ::mlir::TypeRange resultTypes, ::mlir::ValueRange operands
[TableGen] Remove asserts for attributes in aggregate builders Attributes can have default values or be optional. Checking the validity of attributes in aggregate builder should consider that. And to be accurate, we should check all required attributes are indeed provided in the list. This is actually duplicating the work done by verifier. Checking the validity of attributes should be the responsiblity of verifiers. This CL removes the assertion for attributes in aggregate builders for the above reason. (Assertions for operands/results are still kept since they are trivial.) Also added more tests for aggregate builders. -- PiperOrigin-RevId: 241746059
2019-04-04 00:29:25 +08:00
// CHECK: assert(resultTypes.size() == 1u && "mismatched number of return types");
[mlir] Add shaped container component type interface Summary: * Add shaped container type interface which allows infering the shape, element type and attribute of shaped container type separately. Show usage by way of tensor type inference trait which combines the shape & element type in infering a tensor type; - All components need not be specified; - Attribute is added to allow for layout attribute that was previously discussed; * Expand the test driver to make it easier to test new creation instances (adding new operands or ops with attributes or regions would trigger build functions/type inference methods); - The verification part will be moved out of the test and to verify method instead of ops implementing the type inference interface in a follow up; * Add MLIRContext as arg to possible to create type for ops without arguments, region or location; * Also move out the section in OpDefinitions doc to separate ShapeInference doc where the shape function requirements can be captured; - Part of this would move to the shape dialect and/or shape dialect ops be included as subsection of this doc; * Update ODS's variable usage to match camelBack format for builder, state and arg variables; - I could have split this out, but I had to make some changes around these and the inconsistency bugged me :) Differential Revision: https://reviews.llvm.org/D72432
2020-01-09 10:48:38 +08:00
// CHECK-NEXT: odsState.addTypes(resultTypes);
[TableGen] Remove asserts for attributes in aggregate builders Attributes can have default values or be optional. Checking the validity of attributes in aggregate builder should consider that. And to be accurate, we should check all required attributes are indeed provided in the list. This is actually duplicating the work done by verifier. Checking the validity of attributes should be the responsiblity of verifiers. This CL removes the assertion for attributes in aggregate builders for the above reason. (Assertions for operands/results are still kept since they are trivial.) Also added more tests for aggregate builders. -- PiperOrigin-RevId: 241746059
2019-04-04 00:29:25 +08:00
Fix correspondence between trait names in ODS and C++ class names. Make the correspondence between the ODS and C++ side clearer. -- PiperOrigin-RevId: 250211194
2019-05-28 12:18:19 +08:00
def OpB : NS_Op<"same_input_output_type_op", [SameOperandsAndResultType]> {
[TableGen] Use result names in build() methods if possible This will make it clear which result's type we are expecting in the build() signature. PiperOrigin-RevId: 235925706
2019-02-28 00:40:07 +08:00
let arguments = (ins I32:$x);
let results = (outs I32:$y);
}
[TableGen] Support multiple variadic operands/results Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
2019-04-26 05:45:37 +08:00
// CHECK-LABEL: OpB definitions
[mlir-tblgen] Use fully qualified names in generated code files Using fully qualified names wherever possible avoids ambiguous class and function names. This is a follow-up to D82371. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D82471
2020-06-26 19:20:44 +08:00
// CHECK: void OpB::build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::Type y, ::mlir::Value x)
[mlir] Add shaped container component type interface Summary: * Add shaped container type interface which allows infering the shape, element type and attribute of shaped container type separately. Show usage by way of tensor type inference trait which combines the shape & element type in infering a tensor type; - All components need not be specified; - Attribute is added to allow for layout attribute that was previously discussed; * Expand the test driver to make it easier to test new creation instances (adding new operands or ops with attributes or regions would trigger build functions/type inference methods); - The verification part will be moved out of the test and to verify method instead of ops implementing the type inference interface in a follow up; * Add MLIRContext as arg to possible to create type for ops without arguments, region or location; * Also move out the section in OpDefinitions doc to separate ShapeInference doc where the shape function requirements can be captured; - Part of this would move to the shape dialect and/or shape dialect ops be included as subsection of this doc; * Update ODS's variable usage to match camelBack format for builder, state and arg variables; - I could have split this out, but I had to make some changes around these and the inconsistency bugged me :) Differential Revision: https://reviews.llvm.org/D72432
2020-01-09 10:48:38 +08:00
// CHECK: odsState.addTypes(y);
[mlir-tblgen] Use fully qualified names in generated code files Using fully qualified names wherever possible avoids ambiguous class and function names. This is a follow-up to D82371. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D82471
2020-06-26 19:20:44 +08:00
// CHECK: void OpB::build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::Value x)
[mlir] Add shaped container component type interface Summary: * Add shaped container type interface which allows infering the shape, element type and attribute of shaped container type separately. Show usage by way of tensor type inference trait which combines the shape & element type in infering a tensor type; - All components need not be specified; - Attribute is added to allow for layout attribute that was previously discussed; * Expand the test driver to make it easier to test new creation instances (adding new operands or ops with attributes or regions would trigger build functions/type inference methods); - The verification part will be moved out of the test and to verify method instead of ops implementing the type inference interface in a follow up; * Add MLIRContext as arg to possible to create type for ops without arguments, region or location; * Also move out the section in OpDefinitions doc to separate ShapeInference doc where the shape function requirements can be captured; - Part of this would move to the shape dialect and/or shape dialect ops be included as subsection of this doc; * Update ODS's variable usage to match camelBack format for builder, state and arg variables; - I could have split this out, but I had to make some changes around these and the inconsistency bugged me :) Differential Revision: https://reviews.llvm.org/D72432
2020-01-09 10:48:38 +08:00
// CHECK: odsState.addTypes({x.getType()});
[TableGen] Use result names in build() methods if possible This will make it clear which result's type we are expecting in the build() signature. PiperOrigin-RevId: 235925706
2019-02-28 00:40:07 +08:00
Add Dialect in op definition to capture prefix and documentation. Enables specifying the documentation for dialect along with defining the ops of the dialect. The doc generator will be expanded in follow up to emit the documentation in the autogenerated files. This is precursor to allowing common base for all ops in a dialect. All the dialect documentation is super sparse and just added as placeholder. I was tempted (and started) to move ConstantOp to be generated too, but this will be easier post adding extra_methods, so deferring until then. -- PiperOrigin-RevId: 245759984
2019-04-30 00:24:09 +08:00
def OpC : NS_Op<"three_normal_result_op", []> {
[TableGen] Use result names in build() methods if possible This will make it clear which result's type we are expecting in the build() signature. PiperOrigin-RevId: 235925706
2019-02-28 00:40:07 +08:00
let results = (outs I32:$x, /*unnamed*/I32, I32:$z);
}
[TableGen] Support multiple variadic operands/results Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
2019-04-26 05:45:37 +08:00
// CHECK-LABEL: OpC definitions
[mlir-tblgen] Use fully qualified names in generated code files Using fully qualified names wherever possible avoids ambiguous class and function names. This is a follow-up to D82371. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D82471
2020-06-26 19:20:44 +08:00
// CHECK: void OpC::build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::Type x, ::mlir::Type resultType1, ::mlir::Type z)
[mlir] Add shaped container component type interface Summary: * Add shaped container type interface which allows infering the shape, element type and attribute of shaped container type separately. Show usage by way of tensor type inference trait which combines the shape & element type in infering a tensor type; - All components need not be specified; - Attribute is added to allow for layout attribute that was previously discussed; * Expand the test driver to make it easier to test new creation instances (adding new operands or ops with attributes or regions would trigger build functions/type inference methods); - The verification part will be moved out of the test and to verify method instead of ops implementing the type inference interface in a follow up; * Add MLIRContext as arg to possible to create type for ops without arguments, region or location; * Also move out the section in OpDefinitions doc to separate ShapeInference doc where the shape function requirements can be captured; - Part of this would move to the shape dialect and/or shape dialect ops be included as subsection of this doc; * Update ODS's variable usage to match camelBack format for builder, state and arg variables; - I could have split this out, but I had to make some changes around these and the inconsistency bugged me :) Differential Revision: https://reviews.llvm.org/D72432
2020-01-09 10:48:38 +08:00
// CHECK-NEXT: odsState.addTypes(x)
// CHECK-NEXT: odsState.addTypes(resultType1)
// CHECK-NEXT: odsState.addTypes(z)
[TableGen] Use result names in build() methods if possible This will make it clear which result's type we are expecting in the build() signature. PiperOrigin-RevId: 235925706
2019-02-28 00:40:07 +08:00
[MLIR] Change default builders generated by TableGen to use TypeRange for result types - Change the default builders to use TypeRange instead of ArrayRef<Type> - Custom builders defined in LinalgStructuredOps now conflict with the default separate param ones, but the default collective params one is still needed. Resolve this by replicating the collective param builder as a custom builder and skipping the generation of default builders for these ops. Differential Revision: https://reviews.llvm.org/D87926
2020-09-23 11:58:30 +08:00
// CHECK: void OpC::build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::TypeRange resultTypes) {
Verify number of result types in generated builder. Summary: This just bit me and is nasty to debug. Differential Revision: https://reviews.llvm.org/D76888
2020-03-27 05:57:01 +08:00
// CHECK-NEXT: assert(resultTypes.size() == 3u && "mismatched number of results");
// CHECK-NEXT: odsState.addTypes(resultTypes);
Add a trait to set the result type by attribute Before this CL, the result type of the pattern match results need to be as same as the first operand type, operand broadcast type or a generic tensor type. This CL adds a new trait to set the result type by attribute. For example, the TFL_ConstOp can use this to set the output type to its value attribute. PiperOrigin-RevId: 240441249
2019-03-27 06:31:15 +08:00
def IntegerTypeAttr : TypeAttrBase<"IntegerType", "Integer type attribute">;
Add Dialect in op definition to capture prefix and documentation. Enables specifying the documentation for dialect along with defining the ops of the dialect. The doc generator will be expanded in follow up to emit the documentation in the autogenerated files. This is precursor to allowing common base for all ops in a dialect. All the dialect documentation is super sparse and just added as placeholder. I was tempted (and started) to move ConstantOp to be generated too, but this will be easier post adding extra_methods, so deferring until then. -- PiperOrigin-RevId: 245759984
2019-04-30 00:24:09 +08:00
def OpD : NS_Op<"type_attr_as_result_type", [FirstAttrDerivedResultType]> {
Add a trait to set the result type by attribute Before this CL, the result type of the pattern match results need to be as same as the first operand type, operand broadcast type or a generic tensor type. This CL adds a new trait to set the result type by attribute. For example, the TFL_ConstOp can use this to set the output type to its value attribute. PiperOrigin-RevId: 240441249
2019-03-27 06:31:15 +08:00
let arguments = (ins I32:$x, IntegerTypeAttr:$attr, F32Attr:$f32);
Clean up tablegen vector and tensor types There was a weird mix of names, styles, and inheritance here. I think this makes it cleaner and more consistent. We can also have a more principled and far-reaching refactor of some of this naming, but this seems like a good improvement regardless -- PiperOrigin-RevId: 248827005
2019-05-18 10:45:45 +08:00
let results = (outs AnyTensor:$y);
Add a trait to set the result type by attribute Before this CL, the result type of the pattern match results need to be as same as the first operand type, operand broadcast type or a generic tensor type. This CL adds a new trait to set the result type by attribute. For example, the TFL_ConstOp can use this to set the output type to its value attribute. PiperOrigin-RevId: 240441249
2019-03-27 06:31:15 +08:00
}
[TableGen] Support multiple variadic operands/results Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
2019-04-26 05:45:37 +08:00
// CHECK-LABEL: OpD definitions
[mlir-tblgen] Use fully qualified names in generated code files Using fully qualified names wherever possible avoids ambiguous class and function names. This is a follow-up to D82371. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D82471
2020-06-26 19:20:44 +08:00
// CHECK: void OpD::build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::ValueRange operands, ::llvm::ArrayRef<::mlir::NamedAttribute> attributes)
// CHECK: odsState.addTypes({attr.second.cast<::mlir::TypeAttr>().getValue()});
Add a trait to set the result type by attribute Before this CL, the result type of the pattern match results need to be as same as the first operand type, operand broadcast type or a generic tensor type. This CL adds a new trait to set the result type by attribute. For example, the TFL_ConstOp can use this to set the output type to its value attribute. PiperOrigin-RevId: 240441249
2019-03-27 06:31:15 +08:00
Add Dialect in op definition to capture prefix and documentation. Enables specifying the documentation for dialect along with defining the ops of the dialect. The doc generator will be expanded in follow up to emit the documentation in the autogenerated files. This is precursor to allowing common base for all ops in a dialect. All the dialect documentation is super sparse and just added as placeholder. I was tempted (and started) to move ConstantOp to be generated too, but this will be easier post adding extra_methods, so deferring until then. -- PiperOrigin-RevId: 245759984
2019-04-30 00:24:09 +08:00
def OpE : NS_Op<"value_attr_as_result_type", [FirstAttrDerivedResultType]> {
Add a trait to set the result type by attribute Before this CL, the result type of the pattern match results need to be as same as the first operand type, operand broadcast type or a generic tensor type. This CL adds a new trait to set the result type by attribute. For example, the TFL_ConstOp can use this to set the output type to its value attribute. PiperOrigin-RevId: 240441249
2019-03-27 06:31:15 +08:00
let arguments = (ins I32:$x, F32Attr:$attr);
Clean up tablegen vector and tensor types There was a weird mix of names, styles, and inheritance here. I think this makes it cleaner and more consistent. We can also have a more principled and far-reaching refactor of some of this naming, but this seems like a good improvement regardless -- PiperOrigin-RevId: 248827005
2019-05-18 10:45:45 +08:00
let results = (outs AnyTensor:$y);
Add a trait to set the result type by attribute Before this CL, the result type of the pattern match results need to be as same as the first operand type, operand broadcast type or a generic tensor type. This CL adds a new trait to set the result type by attribute. For example, the TFL_ConstOp can use this to set the output type to its value attribute. PiperOrigin-RevId: 240441249
2019-03-27 06:31:15 +08:00
}
[TableGen] Support multiple variadic operands/results Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
2019-04-26 05:45:37 +08:00
// CHECK-LABEL: OpE definitions
[mlir-tblgen] Use fully qualified names in generated code files Using fully qualified names wherever possible avoids ambiguous class and function names. This is a follow-up to D82371. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D82471
2020-06-26 19:20:44 +08:00
// CHECK: void OpE::build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::ValueRange operands, ::llvm::ArrayRef<::mlir::NamedAttribute> attributes)
[mlir] Add shaped container component type interface Summary: * Add shaped container type interface which allows infering the shape, element type and attribute of shaped container type separately. Show usage by way of tensor type inference trait which combines the shape & element type in infering a tensor type; - All components need not be specified; - Attribute is added to allow for layout attribute that was previously discussed; * Expand the test driver to make it easier to test new creation instances (adding new operands or ops with attributes or regions would trigger build functions/type inference methods); - The verification part will be moved out of the test and to verify method instead of ops implementing the type inference interface in a follow up; * Add MLIRContext as arg to possible to create type for ops without arguments, region or location; * Also move out the section in OpDefinitions doc to separate ShapeInference doc where the shape function requirements can be captured; - Part of this would move to the shape dialect and/or shape dialect ops be included as subsection of this doc; * Update ODS's variable usage to match camelBack format for builder, state and arg variables; - I could have split this out, but I had to make some changes around these and the inconsistency bugged me :) Differential Revision: https://reviews.llvm.org/D72432
2020-01-09 10:48:38 +08:00
// CHECK: odsState.addTypes({attr.second.getType()});
Add a trait to set the result type by attribute Before this CL, the result type of the pattern match results need to be as same as the first operand type, operand broadcast type or a generic tensor type. This CL adds a new trait to set the result type by attribute. For example, the TFL_ConstOp can use this to set the output type to its value attribute. PiperOrigin-RevId: 240441249
2019-03-27 06:31:15 +08:00
Add Dialect in op definition to capture prefix and documentation. Enables specifying the documentation for dialect along with defining the ops of the dialect. The doc generator will be expanded in follow up to emit the documentation in the autogenerated files. This is precursor to allowing common base for all ops in a dialect. All the dialect documentation is super sparse and just added as placeholder. I was tempted (and started) to move ConstantOp to be generated too, but this will be easier post adding extra_methods, so deferring until then. -- PiperOrigin-RevId: 245759984
2019-04-30 00:24:09 +08:00
def OpF : NS_Op<"one_variadic_result_op", []> {
Remove checks guaranteed to be true by the type This addresses the compiler wraning of "comparison of unsigned expression >= 0 is always true [-Wtype-limits]". -- PiperOrigin-RevId: 242868703
2019-04-10 23:00:34 +08:00
let results = (outs Variadic<I32>:$x);
}
[TableGen] Support multiple variadic operands/results Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
2019-04-26 05:45:37 +08:00
// CHECK-LABEL: void OpF::build
[MLIR] Change default builders generated by TableGen to use TypeRange for result types - Change the default builders to use TypeRange instead of ArrayRef<Type> - Custom builders defined in LinalgStructuredOps now conflict with the default separate param ones, but the default collective params one is still needed. Resolve this by replicating the collective param builder as a custom builder and skipping the generation of default builders for these ops. Differential Revision: https://reviews.llvm.org/D87926
2020-09-23 11:58:30 +08:00
// CHECK-SAME: ::mlir::TypeRange x
[TableGen] Support multiple variadic operands/results Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
2019-04-26 05:45:37 +08:00
// CHECK-NOT: assert
[mlir] Add shaped container component type interface Summary: * Add shaped container type interface which allows infering the shape, element type and attribute of shaped container type separately. Show usage by way of tensor type inference trait which combines the shape & element type in infering a tensor type; - All components need not be specified; - Attribute is added to allow for layout attribute that was previously discussed; * Expand the test driver to make it easier to test new creation instances (adding new operands or ops with attributes or regions would trigger build functions/type inference methods); - The verification part will be moved out of the test and to verify method instead of ops implementing the type inference interface in a follow up; * Add MLIRContext as arg to possible to create type for ops without arguments, region or location; * Also move out the section in OpDefinitions doc to separate ShapeInference doc where the shape function requirements can be captured; - Part of this would move to the shape dialect and/or shape dialect ops be included as subsection of this doc; * Update ODS's variable usage to match camelBack format for builder, state and arg variables; - I could have split this out, but I had to make some changes around these and the inconsistency bugged me :) Differential Revision: https://reviews.llvm.org/D72432
2020-01-09 10:48:38 +08:00
// CHECK: odsState.addTypes(x);
Remove checks guaranteed to be true by the type This addresses the compiler wraning of "comparison of unsigned expression >= 0 is always true [-Wtype-limits]". -- PiperOrigin-RevId: 242868703
2019-04-10 23:00:34 +08:00
Add Dialect in op definition to capture prefix and documentation. Enables specifying the documentation for dialect along with defining the ops of the dialect. The doc generator will be expanded in follow up to emit the documentation in the autogenerated files. This is precursor to allowing common base for all ops in a dialect. All the dialect documentation is super sparse and just added as placeholder. I was tempted (and started) to move ConstantOp to be generated too, but this will be easier post adding extra_methods, so deferring until then. -- PiperOrigin-RevId: 245759984
2019-04-30 00:24:09 +08:00
def OpG : NS_Op<"one_normal_and_one_variadic_result_op", []> {
Remove checks guaranteed to be true by the type This addresses the compiler wraning of "comparison of unsigned expression >= 0 is always true [-Wtype-limits]". -- PiperOrigin-RevId: 242868703
2019-04-10 23:00:34 +08:00
[TableGen] Use result names in build() methods if possible This will make it clear which result's type we are expecting in the build() signature. PiperOrigin-RevId: 235925706
2019-02-28 00:40:07 +08:00
let results = (outs I32:$x, Variadic<I32>:$y);
}
[TableGen] Support multiple variadic operands/results Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
2019-04-26 05:45:37 +08:00
// CHECK-LABEL: OpG definitions
[TableGen] Remove asserts for attributes in aggregate builders Attributes can have default values or be optional. Checking the validity of attributes in aggregate builder should consider that. And to be accurate, we should check all required attributes are indeed provided in the list. This is actually duplicating the work done by verifier. Checking the validity of attributes should be the responsiblity of verifiers. This CL removes the assertion for attributes in aggregate builders for the above reason. (Assertions for operands/results are still kept since they are trivial.) Also added more tests for aggregate builders. -- PiperOrigin-RevId: 241746059
2019-04-04 00:29:25 +08:00
[MLIR] Change default builders generated by TableGen to use TypeRange for result types - Change the default builders to use TypeRange instead of ArrayRef<Type> - Custom builders defined in LinalgStructuredOps now conflict with the default separate param ones, but the default collective params one is still needed. Resolve this by replicating the collective param builder as a custom builder and skipping the generation of default builders for these ops. Differential Revision: https://reviews.llvm.org/D87926
2020-09-23 11:58:30 +08:00
// CHECK: void OpG::build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::Type x, ::mlir::TypeRange y)
[mlir] Add shaped container component type interface Summary: * Add shaped container type interface which allows infering the shape, element type and attribute of shaped container type separately. Show usage by way of tensor type inference trait which combines the shape & element type in infering a tensor type; - All components need not be specified; - Attribute is added to allow for layout attribute that was previously discussed; * Expand the test driver to make it easier to test new creation instances (adding new operands or ops with attributes or regions would trigger build functions/type inference methods); - The verification part will be moved out of the test and to verify method instead of ops implementing the type inference interface in a follow up; * Add MLIRContext as arg to possible to create type for ops without arguments, region or location; * Also move out the section in OpDefinitions doc to separate ShapeInference doc where the shape function requirements can be captured; - Part of this would move to the shape dialect and/or shape dialect ops be included as subsection of this doc; * Update ODS's variable usage to match camelBack format for builder, state and arg variables; - I could have split this out, but I had to make some changes around these and the inconsistency bugged me :) Differential Revision: https://reviews.llvm.org/D72432
2020-01-09 10:48:38 +08:00
// CHECK-NEXT: odsState.addTypes(x);
// CHECK-NEXT: odsState.addTypes(y);
[TableGen] Remove asserts for attributes in aggregate builders Attributes can have default values or be optional. Checking the validity of attributes in aggregate builder should consider that. And to be accurate, we should check all required attributes are indeed provided in the list. This is actually duplicating the work done by verifier. Checking the validity of attributes should be the responsiblity of verifiers. This CL removes the assertion for attributes in aggregate builders for the above reason. (Assertions for operands/results are still kept since they are trivial.) Also added more tests for aggregate builders. -- PiperOrigin-RevId: 241746059
2019-04-04 00:29:25 +08:00
[ODG] Use getODSOperands() and getODSResults() to back accessors This CL added getODSOperands() and getODSResults() as fallback getter methods for getting all the dynamic values corresponding to a static operand/result (which can be variadic). It should provide a uniform way of calculating the value ranges. All named getter methods are layered on top of these methods now. PiperOrigin-RevId: 252284270
2019-06-09 20:50:09 +08:00
// CHECK: void OpG::build
[MLIR] Change default builders generated by TableGen to use TypeRange for result types - Change the default builders to use TypeRange instead of ArrayRef<Type> - Custom builders defined in LinalgStructuredOps now conflict with the default separate param ones, but the default collective params one is still needed. Resolve this by replicating the collective param builder as a custom builder and skipping the generation of default builders for these ops. Differential Revision: https://reviews.llvm.org/D87926
2020-09-23 11:58:30 +08:00
// CHECK: ::mlir::TypeRange resultTypes
[TableGen] Remove asserts for attributes in aggregate builders Attributes can have default values or be optional. Checking the validity of attributes in aggregate builder should consider that. And to be accurate, we should check all required attributes are indeed provided in the list. This is actually duplicating the work done by verifier. Checking the validity of attributes should be the responsiblity of verifiers. This CL removes the assertion for attributes in aggregate builders for the above reason. (Assertions for operands/results are still kept since they are trivial.) Also added more tests for aggregate builders. -- PiperOrigin-RevId: 241746059
2019-04-04 00:29:25 +08:00
// CHECK: assert(resultTypes.size() >= 1u && "mismatched number of return types");
[mlir] Add shaped container component type interface Summary: * Add shaped container type interface which allows infering the shape, element type and attribute of shaped container type separately. Show usage by way of tensor type inference trait which combines the shape & element type in infering a tensor type; - All components need not be specified; - Attribute is added to allow for layout attribute that was previously discussed; * Expand the test driver to make it easier to test new creation instances (adding new operands or ops with attributes or regions would trigger build functions/type inference methods); - The verification part will be moved out of the test and to verify method instead of ops implementing the type inference interface in a follow up; * Add MLIRContext as arg to possible to create type for ops without arguments, region or location; * Also move out the section in OpDefinitions doc to separate ShapeInference doc where the shape function requirements can be captured; - Part of this would move to the shape dialect and/or shape dialect ops be included as subsection of this doc; * Update ODS's variable usage to match camelBack format for builder, state and arg variables; - I could have split this out, but I had to make some changes around these and the inconsistency bugged me :) Differential Revision: https://reviews.llvm.org/D72432
2020-01-09 10:48:38 +08:00
// CHECK-NEXT: odsState.addTypes(resultTypes);
[TableGen] Support multiple variadic operands/results Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
2019-04-26 05:45:37 +08:00
[ODG] Use getODSOperands() and getODSResults() to back accessors This CL added getODSOperands() and getODSResults() as fallback getter methods for getting all the dynamic values corresponding to a static operand/result (which can be variadic). It should provide a uniform way of calculating the value ranges. All named getter methods are layered on top of these methods now. PiperOrigin-RevId: 252284270
2019-06-09 20:50:09 +08:00
def OpI : NS_Op<"mix_variadic_and_normal_results_op", [SameVariadicResultSize]> {
let results = (outs Variadic<AnyTensor>:$output1, AnyTensor:$output2, Variadic<AnyTensor>:$output3);
[TableGen] Support multiple variadic operands/results Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
2019-04-26 05:45:37 +08:00
}
[mlir-tblgen] Use fully qualified names in generated code files Using fully qualified names wherever possible avoids ambiguous class and function names. This is a follow-up to D82371. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D82471
2020-06-26 19:20:44 +08:00
// CHECK-LABEL: ::mlir::Operation::result_range OpI::output1
[ODG] Use getODSOperands() and getODSResults() to back accessors This CL added getODSOperands() and getODSResults() as fallback getter methods for getting all the dynamic values corresponding to a static operand/result (which can be variadic). It should provide a uniform way of calculating the value ranges. All named getter methods are layered on top of these methods now. PiperOrigin-RevId: 252284270
2019-06-09 20:50:09 +08:00
// CHECK-NEXT: return getODSResults(0);
[TableGen] Support multiple variadic operands/results Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
2019-04-26 05:45:37 +08:00
[mlir-tblgen] Use fully qualified names in generated code files Using fully qualified names wherever possible avoids ambiguous class and function names. This is a follow-up to D82371. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D82471
2020-06-26 19:20:44 +08:00
// CHECK-LABEL: ::mlir::Value OpI::output2
[ODG] Use getODSOperands() and getODSResults() to back accessors This CL added getODSOperands() and getODSResults() as fallback getter methods for getting all the dynamic values corresponding to a static operand/result (which can be variadic). It should provide a uniform way of calculating the value ranges. All named getter methods are layered on top of these methods now. PiperOrigin-RevId: 252284270
2019-06-09 20:50:09 +08:00
// CHECK-NEXT: return *getODSResults(1).begin();
[TableGen] Support multiple variadic operands/results Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
2019-04-26 05:45:37 +08:00
// CHECK-LABEL: OpI::build
[mlir] Add shaped container component type interface Summary: * Add shaped container type interface which allows infering the shape, element type and attribute of shaped container type separately. Show usage by way of tensor type inference trait which combines the shape & element type in infering a tensor type; - All components need not be specified; - Attribute is added to allow for layout attribute that was previously discussed; * Expand the test driver to make it easier to test new creation instances (adding new operands or ops with attributes or regions would trigger build functions/type inference methods); - The verification part will be moved out of the test and to verify method instead of ops implementing the type inference interface in a follow up; * Add MLIRContext as arg to possible to create type for ops without arguments, region or location; * Also move out the section in OpDefinitions doc to separate ShapeInference doc where the shape function requirements can be captured; - Part of this would move to the shape dialect and/or shape dialect ops be included as subsection of this doc; * Update ODS's variable usage to match camelBack format for builder, state and arg variables; - I could have split this out, but I had to make some changes around these and the inconsistency bugged me :) Differential Revision: https://reviews.llvm.org/D72432
2020-01-09 10:48:38 +08:00
// CHECK-NEXT: odsState.addTypes(output1);
// CHECK-NEXT: odsState.addTypes(output2);
// CHECK-NEXT: odsState.addTypes(output3);
[TableGen] Support multiple variadic operands/results Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
2019-04-26 05:45:37 +08:00
Fix minor spelling tweaks (NFC) Closes tensorflow/mlir#175 PiperOrigin-RevId: 275726876
2019-10-21 00:44:06 +08:00
// Test that if the only operand is variadic, we access the first value in the
[TableGen] Support multiple variadic operands/results Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
2019-04-26 05:45:37 +08:00
// pack to set result type
// ---
Fix correspondence between trait names in ODS and C++ class names. Make the correspondence between the ODS and C++ side clearer. -- PiperOrigin-RevId: 250211194
2019-05-28 12:18:19 +08:00
def OpK : NS_Op<"only_input_is_variadic_with_same_value_type_op", [SameOperandsAndResultType]> {
Clean up tablegen vector and tensor types There was a weird mix of names, styles, and inheritance here. I think this makes it cleaner and more consistent. We can also have a more principled and far-reaching refactor of some of this naming, but this seems like a good improvement regardless -- PiperOrigin-RevId: 248827005
2019-05-18 10:45:45 +08:00
let arguments = (ins Variadic<AnyTensor>:$input);
let results = (outs AnyTensor:$result);
[TableGen] Support multiple variadic operands/results Certain ops can have multiple variadic operands/results, e.g., `tf.DynamicStitch`. Even if an op has only one variadic operand/result, it is not necessarily the very last one, e.g., `tf.RaggedGather`. This CL enhances TableGen subsystem to be able to represent such cases. In order to deduce the operand/result value range for each variadic operand, currently we only support variadic operands/results all of the same size. So two new traits, `SameVariadicOperandSize` and `SameVariadicResultSize` are introduced. -- PiperOrigin-RevId: 245310628
2019-04-26 05:45:37 +08:00
}
[MLIR][TableGen] Automatic detection and elimination of redundant methods - Change OpClass new method addition to find and eliminate any existing methods that are made redundant by the newly added method, as well as detect if the newly added method will be redundant and return nullptr in that case. - To facilitate that, add the notion of resolved and unresolved parameters, where resolved parameters have each parameter type known, so that redundancy checks on methods with same name but different parameter types can be done. - Eliminate existing code to avoid adding conflicting/redundant build methods and rely on this new mechanism to eliminate conflicting build methods. Fixes https://bugs.llvm.org/show_bug.cgi?id=47095 Differential Revision: https://reviews.llvm.org/D87059
2020-09-18 04:18:09 +08:00
// CHECK-LABEL: OpK::build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::ValueRange operands, ::llvm::ArrayRef<::mlir::NamedAttribute> attributes)
[MLIR][TableGen] Fix ambiguous build methods when inferring result types. - Fix ODS framework to suppress build methods that infer result types and are ambiguous with collective variants. This applies to operations with a single variadic inputs whose result types can be inferred. - Extended OpBuildGenTest to test these kinds of ops. Differential Revision: https://reviews.llvm.org/D85060
2020-08-08 05:02:19 +08:00
// CHECK: odsState.addTypes({operands[0].getType()});
[ods] Update Operator to record Arg->[Attr|Operand]Index mapping Also fixed bug in type inferface generator to address bug where operands and attributes are interleaved. Differential Revision: https://reviews.llvm.org/D82819
2020-06-30 07:40:52 +08:00
// Test with inferred shapes and interleaved with operands/attributes.
//
def OpL : NS_Op<"op_with_all_types_constraint",
[AllTypesMatch<["a", "b"]>]> {
let arguments = (ins I32Attr:$attr1, AnyType:$a);
let results = (outs Res<AnyType, "output b", []>:$b);
}
// CHECK-LABEL: LogicalResult OpL::inferReturnTypes
// CHECK-NOT: }
// CHECK: inferredReturnTypes[0] = operands[0].getType();