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-operand.td

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

61 lines
1.8 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] 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
include "mlir/IR/OpBase.td"
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_operand_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 arguments = (ins I32:$input);
}
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
// CHECK-LABEL: OpA definitions
[TableGen] Change names for Builder* and OperationState* parameters to avoid collision The `Builder*` parameter is unused in both generated build() methods so that we can leave it unnamed. Changed stand-alone parameter build() to take `_tblgen_state` instead of `result` to allow `result` to avoid having name collisions with op operand, attribute, or result. PiperOrigin-RevId: 240637700
2019-03-28 05:09:19 +08:00
[mlir] Remove OperandAdaptor Use ::Adaptor alias instead uniformly. Makes the naming more consistent as adaptor can refer to attributes now too. Differential Revision: https://reviews.llvm.org/D81789
2020-06-15 21:01:31 +08:00
// CHECK: OpAAdaptor::OpAAdaptor
[mlir] Use ValueRange instead of ArrayRef<Value> This allows constructing operand adaptor from existing op (useful for commonalizing verification as I want to do in a follow up). I also add ability to use member initializers for the generated adaptor constructors for convenience. Differential Revision: https://reviews.llvm.org/D80667
2020-05-29 00:05:24 +08:00
// CHECK-SAME: odsOperands(values), odsAttrs(attrs)
Introduce OpOperandAdaptors and emit them from ODS When manipulating generic operations, such as in dialect conversion / rewriting, it is often necessary to view a list of Values as operands to an operation without creating the operation itself. The absence of such view makes dialect conversion patterns, among others, to use magic numbers to obtain specific operands from a list of rewritten values when converting an operation. Introduce XOpOperandAdaptor classes that wrap an ArrayRef<Value *> and provide accessor functions identical to those available in XOp. This makes it possible for conversions to use these adaptors to address the operands with names rather than rely on their position in the list. The adaptors are generated from ODS together with the actual operation definitions. This is another step towards making dialect conversion patterns specific for a given operation. Illustrate the approach on conversion patterns in the standard to LLVM dialect conversion. PiperOrigin-RevId: 251232899
2019-06-03 23:03:20 +08:00
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
// CHECK: void OpA::build
[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: ::mlir::Value input
[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.addOperands(input);
[TableGen] Change names for Builder* and OperationState* parameters to avoid collision The `Builder*` parameter is unused in both generated build() methods so that we can leave it unnamed. Changed stand-alone parameter build() to take `_tblgen_state` instead of `result` to allow `result` to avoid having name collisions with op operand, attribute, or result. PiperOrigin-RevId: 240637700
2019-03-28 05:09:19 +08:00
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
// CHECK: void OpA::build
[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: ::mlir::ValueRange operands
[TableGen] Change names for Builder* and OperationState* parameters to avoid collision The `Builder*` parameter is unused in both generated build() methods so that we can leave it unnamed. Changed stand-alone parameter build() to take `_tblgen_state` instead of `result` to allow `result` to avoid having name collisions with op operand, attribute, or result. PiperOrigin-RevId: 240637700
2019-03-28 05:09:19 +08:00
// CHECK: assert(operands.size() == 1u && "mismatched number of parameters");
[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.addOperands(operands);
[TableGen] Change names for Builder* and OperationState* parameters to avoid collision The `Builder*` parameter is unused in both generated build() methods so that we can leave it unnamed. Changed stand-alone parameter build() to take `_tblgen_state` instead of `result` to allow `result` to avoid having name collisions with op operand, attribute, or result. PiperOrigin-RevId: 240637700
2019-03-28 05:09:19 +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 OpB : NS_Op<"one_variadic_operand_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 arguments = (ins Variadic<I32>:$input);
}
// CHECK-LABEL: OpB::build
[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: ::mlir::ValueRange input
[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.addOperands(input);
[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 OpD : NS_Op<"mix_variadic_and_normal_inputs_op", [SameVariadicOperandSize]> {
let arguments = (ins Variadic<AnyTensor>:$input1, AnyTensor:$input2, Variadic<AnyTensor>:$input3);
[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::ValueRange OpDAdaptor::input1
[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 getODSOperands(0);
Introduce OpOperandAdaptors and emit them from ODS When manipulating generic operations, such as in dialect conversion / rewriting, it is often necessary to view a list of Values as operands to an operation without creating the operation itself. The absence of such view makes dialect conversion patterns, among others, to use magic numbers to obtain specific operands from a list of rewritten values when converting an operation. Introduce XOpOperandAdaptor classes that wrap an ArrayRef<Value *> and provide accessor functions identical to those available in XOp. This makes it possible for conversions to use these adaptors to address the operands with names rather than rely on their position in the list. The adaptors are generated from ODS together with the actual operation definitions. This is another step towards making dialect conversion patterns specific for a given operation. Illustrate the approach on conversion patterns in the standard to LLVM dialect conversion. PiperOrigin-RevId: 251232899
2019-06-03 23:03:20 +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 OpDAdaptor::input2
[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 *getODSOperands(1).begin();
Introduce OpOperandAdaptors and emit them from ODS When manipulating generic operations, such as in dialect conversion / rewriting, it is often necessary to view a list of Values as operands to an operation without creating the operation itself. The absence of such view makes dialect conversion patterns, among others, to use magic numbers to obtain specific operands from a list of rewritten values when converting an operation. Introduce XOpOperandAdaptor classes that wrap an ArrayRef<Value *> and provide accessor functions identical to those available in XOp. This makes it possible for conversions to use these adaptors to address the operands with names rather than rely on their position in the list. The adaptors are generated from ODS together with the actual operation definitions. This is another step towards making dialect conversion patterns specific for a given operation. Illustrate the approach on conversion patterns in the standard to LLVM dialect conversion. PiperOrigin-RevId: 251232899
2019-06-03 23:03:20 +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::ValueRange OpDAdaptor::input3
[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 getODSOperands(2);
[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::operand_range OpD::input1
[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 getODSOperands(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 OpD::input2
[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 *getODSOperands(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: OpD::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.addOperands(input1);
// CHECK-NEXT: odsState.addOperands(input2);
// CHECK-NEXT: odsState.addOperands(input3);