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
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
// CHECK: OpAOperandAdaptor::OpAOperandAdaptor
// CHECK-NEXT: tblgen_operands = values
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
NFC: Replace ValuePtr with Value and remove it now that Value is value-typed. ValuePtr was a temporary typedef during the transition to a value-typed Value. PiperOrigin-RevId: 286945714
2019-12-24 06:45:01 +08:00
// CHECK: Value input
NFC: Pass OperationState by reference instead of by pointer. MLIR follows the LLVM convention of passing by reference instead of by pointer. PiperOrigin-RevId: 270396945
2019-09-21 10:47:05 +08:00
// CHECK: tblgen_state.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
Fix logic on when to emit collective type but separate arg builder Got the comment right but the code wrong :/ PiperOrigin-RevId: 285270561
2019-12-13 06:22:40 +08:00
// CHECK: 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");
NFC: Pass OperationState by reference instead of by pointer. MLIR follows the LLVM convention of passing by reference instead of by pointer. PiperOrigin-RevId: 270396945
2019-09-21 10:47:05 +08:00
// CHECK: tblgen_state.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
Fix logic on when to emit collective type but separate arg builder Got the comment right but the code wrong :/ PiperOrigin-RevId: 285270561
2019-12-13 06:22:40 +08:00
// CHECK: 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
NFC: Pass OperationState by reference instead of by pointer. MLIR follows the LLVM convention of passing by reference instead of by pointer. PiperOrigin-RevId: 270396945
2019-09-21 10:47:05 +08:00
// CHECK: tblgen_state.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
}
NFC: Replace ValuePtr with Value and remove it now that Value is value-typed. ValuePtr was a temporary typedef during the transition to a value-typed Value. PiperOrigin-RevId: 286945714
2019-12-24 06:45:01 +08:00
// CHECK-LABEL: ArrayRef<Value> OpDOperandAdaptor::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
NFC: Replace ValuePtr with Value and remove it now that Value is value-typed. ValuePtr was a temporary typedef during the transition to a value-typed Value. PiperOrigin-RevId: 286945714
2019-12-24 06:45:01 +08:00
// CHECK-LABEL: Value OpDOperandAdaptor::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
NFC: Replace ValuePtr with Value and remove it now that Value is value-typed. ValuePtr was a temporary typedef during the transition to a value-typed Value. PiperOrigin-RevId: 286945714
2019-12-24 06:45:01 +08:00
// CHECK-LABEL: ArrayRef<Value> OpDOperandAdaptor::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
[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-LABEL: Operation::operand_range OpD::input1
// 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
NFC: Replace ValuePtr with Value and remove it now that Value is value-typed. ValuePtr was a temporary typedef during the transition to a value-typed Value. PiperOrigin-RevId: 286945714
2019-12-24 06:45:01 +08:00
// CHECK-LABEL: 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
NFC: Pass OperationState by reference instead of by pointer. MLIR follows the LLVM convention of passing by reference instead of by pointer. PiperOrigin-RevId: 270396945
2019-09-21 10:47:05 +08:00
// CHECK-NEXT: tblgen_state.addOperands(input1);
// CHECK-NEXT: tblgen_state.addOperands(input2);
// CHECK-NEXT: tblgen_state.addOperands(input3);