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/predicate.td

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

97 lines
3.8 KiB
TableGen
Raw Normal View History

Change filecheck default to dump input on failure Having the input dumped on failure seems like a better default: I debugged FileCheck tests for a while without knowing about this option, which really helps to understand failures. Remove `-dump-input-on-failure` and the environment variable FILECHECK_DUMP_INPUT_ON_FAILURE which are now obsolete. Differential Revision: https://reviews.llvm.org/D81422
2020-03-28 07:58:06 +08:00
// RUN: mlir-tblgen -gen-op-defs -I %S/../../include %s | FileCheck %s
[TableGen] Fix infinite loop in SubstLeaves substitution Previously we have `auto pos = std::string::find(...) != std::string::npos` as if condition to control substring substitution. Instead of the position for the found substring, `pos` will be a boolean value indicating found nor not. Then used as the replace start position, we were always replacing starting from 0 or 1. If the replaced substring also has the pattern to be matched, we'll see an infinite loop. PiperOrigin-RevId: 235504681
2019-02-25 20:03:02 +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"
[TableGen] Fix infinite loop in SubstLeaves substitution Previously we have `auto pos = std::string::find(...) != std::string::npos` as if condition to control substring substitution. Instead of the position for the found substring, `pos` will be a boolean value indicating found nor not. Then used as the replace start position, we were always replacing starting from 0 or 1. If the replaced substring also has the pattern to be matched, we'll see an infinite loop. PiperOrigin-RevId: 235504681
2019-02-25 20:03:02 +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>;
[TableGen] Use `tgfmt` to format various predicates and rewrite rules This CL changes various predicates and rewrite rules to use $-placeholders and `tgfmt` as the driver for substitution. This will make the predicates and rewrite rules more consistent regarding their arguments and more readable. -- PiperOrigin-RevId: 243250739
2019-04-12 21:05:49 +08:00
def I32OrF32 : Type<CPred<"$_self.isInteger(32) || $_self.isF32()">,
[TableGen] Fix infinite loop in SubstLeaves substitution Previously we have `auto pos = std::string::find(...) != std::string::npos` as if condition to control substring substitution. Instead of the position for the found substring, `pos` will be a boolean value indicating found nor not. Then used as the replace start position, we were always replacing starting from 0 or 1. If the replaced substring also has the pattern to be matched, we'll see an infinite loop. PiperOrigin-RevId: 235504681
2019-02-25 20:03:02 +08:00
"32-bit integer or floating-point type">;
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 OpA : NS_Op<"op_for_CPred_containing_multiple_same_placeholder", []> {
[TableGen] Rework verifier generation and error messages Previously we bundle the existence check and the MLIR attribute kind check in one call. Further constraints (like element bitwidth) have to be split into following checks. That is not a nice separation given that we have more checks for constraints. Instead, this CL changes to generate a local variable for every attribute, check its existence first, then check the constraints. Creating a local variable for each attribute also avoids querying it multiple times using the raw getAttr() API. This is a win for both performance the readability of the generated code. This CL also changed the error message to be more greppable by delimiting the error message from constraints with boilerplate part with colon. -- PiperOrigin-RevId: 241906132
2019-04-04 19:29:58 +08:00
let arguments = (ins I32OrF32:$x);
Fix missing parenthesis around negation. This should probably be changed to instead use the negated form (e.g., get predicate + negate it + get resulting template), but this fixes it locally. PiperOrigin-RevId: 240067116
2019-03-25 10:35:20 +08:00
}
[TableGen] Rework verifier generation and error messages Previously we bundle the existence check and the MLIR attribute kind check in one call. Further constraints (like element bitwidth) have to be split into following checks. That is not a nice separation given that we have more checks for constraints. Instead, this CL changes to generate a local variable for every attribute, check its existence first, then check the constraints. Creating a local variable for each attribute also avoids querying it multiple times using the raw getAttr() API. This is a win for both performance the readability of the generated code. This CL also changed the error message to be more greppable by delimiting the error message from constraints with boilerplate part with colon. -- PiperOrigin-RevId: 241906132
2019-04-04 19:29:58 +08:00
// CHECK-LABEL: OpA::verify
[mlir][ODS] Add support for optional operands and results with a new Optional directive. Summary: This revision adds support for specifying operands or results as "optional". This is a special case of variadic where the number of elements is either 0 or 1. Operands and results of this kind will have accessors generated using Value instead of the range types, making it more natural to interface with. Differential Revision: https://reviews.llvm.org/D77863
2020-04-11 05:11:45 +08:00
// CHECK: auto valueGroup0 = getODSOperands(0);
[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: for (::mlir::Value v : valueGroup0) {
[mlir] NFC: Remove Value::operator* and Value::operator-> now that Value is properly value-typed. Summary: These were temporary methods used to simplify the transition. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D72548
2020-01-12 00:54:04 +08:00
// CHECK: if (!((v.getType().isInteger(32) || v.getType().isF32())))
Support for type constraints across operand and results -- PiperOrigin-RevId: 240905555
2019-03-29 10:49:31 +08:00
Rename "AnyOf" and "AllOf" combined predicates to "Or" and "And", respectively. This reduces conflict between these and other type names, where we're moving towards "Of" indicating a container type containing certain types. It also better matches the "Neg" predicate modifier and generally is pretty understandable/readable for predicates. -- PiperOrigin-RevId: 249076508
2019-05-21 01:31:32 +08:00
def OpB : NS_Op<"op_for_And_PredOpTrait", [
PredOpTrait<"both first and second holds",
And<[CPred<"first">, CPred<"second">]>>]> {
[TableGen] Fix infinite loop in SubstLeaves substitution Previously we have `auto pos = std::string::find(...) != std::string::npos` as if condition to control substring substitution. Instead of the position for the found substring, `pos` will be a boolean value indicating found nor not. Then used as the replace start position, we were always replacing starting from 0 or 1. If the replaced substring also has the pattern to be matched, we'll see an infinite loop. PiperOrigin-RevId: 235504681
2019-02-25 20:03:02 +08:00
}
[TableGen] Rework verifier generation and error messages Previously we bundle the existence check and the MLIR attribute kind check in one call. Further constraints (like element bitwidth) have to be split into following checks. That is not a nice separation given that we have more checks for constraints. Instead, this CL changes to generate a local variable for every attribute, check its existence first, then check the constraints. Creating a local variable for each attribute also avoids querying it multiple times using the raw getAttr() API. This is a win for both performance the readability of the generated code. This CL also changed the error message to be more greppable by delimiting the error message from constraints with boilerplate part with colon. -- PiperOrigin-RevId: 241906132
2019-04-04 19:29:58 +08:00
// CHECK-LABEL: OpB::verify
// CHECK: if (!(((first)) && ((second))))
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<"op_for_int_min_val", []> {
[TableGen] Add Confined, IntMinValue, and ArrayMinCount for attribute constraints This CL introduces Confined as a general mechanism to compose complex attribute constraints out of more primitive ones. It's particularly useful for automatically generating op definitions from some external source, where we can have random combinations of primitive constraints and it would be impractical to define a case for each of such combination. Two primitive attribute constraints, IntMinValue and ArrayMinCount, are added to be used together with Confined. -- PiperOrigin-RevId: 241435955
2019-04-02 08:40:58 +08:00
let arguments = (ins Confined<I32Attr, [IntMinValue<10>]>:$attr);
}
[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-LABEL: OpFAdaptor::verify
[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: (tblgen_attr.cast<::mlir::IntegerAttr>().getInt() >= 10)
[mlir] Add verify method to adaptor This allows verifying op-indepent attributes (e.g., attributes that do not require the op to have been created) before constructing an operation. These include checking whether required attributes are defined or constraints on attributes (such as I32 attribute). This is not perfect (e.g., if one had a disjunctive constraint where one part relied on the op and the other doesn't, then this would not try and extract the op independent from the op dependent). The next step is to move these out to a trait that could be verified earlier than in the generated method. The first use case is for inferring the return type while constructing the op. At that point you don't have an Operation yet and that ends up in one having to duplicate the same checks, e.g., verify that attribute A is defined before querying A in shape function which requires that duplication. Instead this allows one to invoke a method to verify all the traits and, if this is checked first during verification, then all other traits could use attributes knowing they have been verified. It is a little bit funny to have these on the adaptor, but I see the adaptor as a place to collect information about the op before the op is constructed (e.g., avoiding stringly typed accessors, verifying what is possible to verify before the op is constructed) while being cheap to use even with constructed op (so layer of indirection between the op constructed/being constructed). And from that point of view it made sense to me. Differential Revision: https://reviews.llvm.org/D80842
2020-06-06 00:47:37 +08:00
// CHECK-SAME: "attribute 'attr' failed to satisfy constraint: 32-bit signless integer attribute whose minimum value is 10"
Introduce prefetch op: affine -> std -> llvm intrinsic Introduce affine.prefetch: op to prefetch using a multi-dimensional subscript on a memref; similar to affine.load but has no effect on semantics, but only on performance. Provide lowering through std.prefetch, llvm.prefetch and map to llvm's prefetch instrinsic. All attributes reflected through the lowering - locality hint, rw, and instr/data cache. affine.prefetch %0[%i, %j + 5], false, 3, true : memref<400x400xi32> Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#225 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/225 from bondhugula:prefetch 4c3b4e93bc64d9a5719504e6d6e1657818a2ead0 PiperOrigin-RevId: 286212997
2019-12-19 01:59:37 +08:00
def OpFX : NS_Op<"op_for_int_max_val", []> {
let arguments = (ins Confined<I32Attr, [IntMaxValue<10>]>:$attr);
}
[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-LABEL: OpFXAdaptor::verify
[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: (tblgen_attr.cast<::mlir::IntegerAttr>().getInt() <= 10)
[mlir] Add verify method to adaptor This allows verifying op-indepent attributes (e.g., attributes that do not require the op to have been created) before constructing an operation. These include checking whether required attributes are defined or constraints on attributes (such as I32 attribute). This is not perfect (e.g., if one had a disjunctive constraint where one part relied on the op and the other doesn't, then this would not try and extract the op independent from the op dependent). The next step is to move these out to a trait that could be verified earlier than in the generated method. The first use case is for inferring the return type while constructing the op. At that point you don't have an Operation yet and that ends up in one having to duplicate the same checks, e.g., verify that attribute A is defined before querying A in shape function which requires that duplication. Instead this allows one to invoke a method to verify all the traits and, if this is checked first during verification, then all other traits could use attributes knowing they have been verified. It is a little bit funny to have these on the adaptor, but I see the adaptor as a place to collect information about the op before the op is constructed (e.g., avoiding stringly typed accessors, verifying what is possible to verify before the op is constructed) while being cheap to use even with constructed op (so layer of indirection between the op constructed/being constructed). And from that point of view it made sense to me. Differential Revision: https://reviews.llvm.org/D80842
2020-06-06 00:47:37 +08:00
// CHECK-SAME: "attribute 'attr' failed to satisfy constraint: 32-bit signless integer attribute whose maximum value is 10"
[TableGen] Add Confined, IntMinValue, and ArrayMinCount for attribute constraints This CL introduces Confined as a general mechanism to compose complex attribute constraints out of more primitive ones. It's particularly useful for automatically generating op definitions from some external source, where we can have random combinations of primitive constraints and it would be impractical to define a case for each of such combination. Two primitive attribute constraints, IntMinValue and ArrayMinCount, are added to be used together with Confined. -- PiperOrigin-RevId: 241435955
2019-04-02 08:40:58 +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<"op_for_arr_min_count", []> {
[TableGen] Add Confined, IntMinValue, and ArrayMinCount for attribute constraints This CL introduces Confined as a general mechanism to compose complex attribute constraints out of more primitive ones. It's particularly useful for automatically generating op definitions from some external source, where we can have random combinations of primitive constraints and it would be impractical to define a case for each of such combination. Two primitive attribute constraints, IntMinValue and ArrayMinCount, are added to be used together with Confined. -- PiperOrigin-RevId: 241435955
2019-04-02 08:40:58 +08:00
let arguments = (ins Confined<ArrayAttr, [ArrayMinCount<8>]>:$attr);
}
[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-LABEL: OpGAdaptor::verify
[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: (tblgen_attr.cast<::mlir::ArrayAttr>().size() >= 8)
[mlir] Add verify method to adaptor This allows verifying op-indepent attributes (e.g., attributes that do not require the op to have been created) before constructing an operation. These include checking whether required attributes are defined or constraints on attributes (such as I32 attribute). This is not perfect (e.g., if one had a disjunctive constraint where one part relied on the op and the other doesn't, then this would not try and extract the op independent from the op dependent). The next step is to move these out to a trait that could be verified earlier than in the generated method. The first use case is for inferring the return type while constructing the op. At that point you don't have an Operation yet and that ends up in one having to duplicate the same checks, e.g., verify that attribute A is defined before querying A in shape function which requires that duplication. Instead this allows one to invoke a method to verify all the traits and, if this is checked first during verification, then all other traits could use attributes knowing they have been verified. It is a little bit funny to have these on the adaptor, but I see the adaptor as a place to collect information about the op before the op is constructed (e.g., avoiding stringly typed accessors, verifying what is possible to verify before the op is constructed) while being cheap to use even with constructed op (so layer of indirection between the op constructed/being constructed). And from that point of view it made sense to me. Differential Revision: https://reviews.llvm.org/D80842
2020-06-06 00:47:37 +08:00
// CHECK-SAME: "attribute 'attr' failed to satisfy constraint: array attribute with at least 8 elements"
Add attr constraint support to constrain IntegerArray attribute values at a specified index. -- PiperOrigin-RevId: 242209394
2019-04-06 06:51:47 +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 OpH : NS_Op<"op_for_arr_value_at_index", []> {
Add attr constraint support to constrain IntegerArray attribute values at a specified index. -- PiperOrigin-RevId: 242209394
2019-04-06 06:51:47 +08:00
let arguments = (ins Confined<ArrayAttr, [IntArrayNthElemEq<0, 8>]>:$attr);
}
[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-LABEL: OpHAdaptor::verify
[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: (((tblgen_attr.cast<::mlir::ArrayAttr>().size() > 0)) && ((tblgen_attr.cast<::mlir::ArrayAttr>()[0].cast<::mlir::IntegerAttr>().getInt() == 8)))))
[mlir] Add verify method to adaptor This allows verifying op-indepent attributes (e.g., attributes that do not require the op to have been created) before constructing an operation. These include checking whether required attributes are defined or constraints on attributes (such as I32 attribute). This is not perfect (e.g., if one had a disjunctive constraint where one part relied on the op and the other doesn't, then this would not try and extract the op independent from the op dependent). The next step is to move these out to a trait that could be verified earlier than in the generated method. The first use case is for inferring the return type while constructing the op. At that point you don't have an Operation yet and that ends up in one having to duplicate the same checks, e.g., verify that attribute A is defined before querying A in shape function which requires that duplication. Instead this allows one to invoke a method to verify all the traits and, if this is checked first during verification, then all other traits could use attributes knowing they have been verified. It is a little bit funny to have these on the adaptor, but I see the adaptor as a place to collect information about the op before the op is constructed (e.g., avoiding stringly typed accessors, verifying what is possible to verify before the op is constructed) while being cheap to use even with constructed op (so layer of indirection between the op constructed/being constructed). And from that point of view it made sense to me. Differential Revision: https://reviews.llvm.org/D80842
2020-06-06 00:47:37 +08:00
// CHECK-SAME: "attribute 'attr' failed to satisfy constraint: array attribute whose 0-th element must be 8"
Add attr constraint support to constrain IntegerArray attribute values at a specified index. -- PiperOrigin-RevId: 242209394
2019-04-06 06:51:47 +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 OpI: NS_Op<"op_for_arr_min_value_at_index", []> {
Add attr constraint support to constrain IntegerArray attribute values at a specified index. -- PiperOrigin-RevId: 242209394
2019-04-06 06:51:47 +08:00
let arguments = (ins Confined<ArrayAttr, [IntArrayNthElemMinValue<0, 8>]>:$attr);
}
[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-LABEL: OpIAdaptor::verify
[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: (((tblgen_attr.cast<::mlir::ArrayAttr>().size() > 0)) && ((tblgen_attr.cast<::mlir::ArrayAttr>()[0].cast<::mlir::IntegerAttr>().getInt() >= 8)))))
[mlir] Add verify method to adaptor This allows verifying op-indepent attributes (e.g., attributes that do not require the op to have been created) before constructing an operation. These include checking whether required attributes are defined or constraints on attributes (such as I32 attribute). This is not perfect (e.g., if one had a disjunctive constraint where one part relied on the op and the other doesn't, then this would not try and extract the op independent from the op dependent). The next step is to move these out to a trait that could be verified earlier than in the generated method. The first use case is for inferring the return type while constructing the op. At that point you don't have an Operation yet and that ends up in one having to duplicate the same checks, e.g., verify that attribute A is defined before querying A in shape function which requires that duplication. Instead this allows one to invoke a method to verify all the traits and, if this is checked first during verification, then all other traits could use attributes knowing they have been verified. It is a little bit funny to have these on the adaptor, but I see the adaptor as a place to collect information about the op before the op is constructed (e.g., avoiding stringly typed accessors, verifying what is possible to verify before the op is constructed) while being cheap to use even with constructed op (so layer of indirection between the op constructed/being constructed). And from that point of view it made sense to me. Differential Revision: https://reviews.llvm.org/D80842
2020-06-06 00:47:37 +08:00
// CHECK-SAME: "attribute 'attr' failed to satisfy constraint: array attribute whose 0-th element must be at least 8"
[TableGen] Add the `TCopVTEtAreSameAt` PredOpTrait This trait is used for specifying operands at the indices from a given list are with the same element type. -- PiperOrigin-RevId: 246364735
2019-05-03 03:08:17 +08:00
[TableGen] Couple of small updates to OpBase Added a definition for the newly added None type. Fix TCopVTEtAreSameAt to be a Predicate rather than a PredOpTrait. This makes it more of a primitive and allows flexible composition. -- PiperOrigin-RevId: 246631975
2019-05-04 16:00:25 +08:00
def OpJ: NS_Op<"op_for_TCopVTEtAreSameAt", [
PredOpTrait<"operands indexed at 0, 2, 3 should all have "
"the same type", TCopVTEtAreSameAt<[0, 2, 3]>>]> {
[TableGen] Add the `TCopVTEtAreSameAt` PredOpTrait This trait is used for specifying operands at the indices from a given list are with the same element type. -- PiperOrigin-RevId: 246364735
2019-05-03 03:08:17 +08:00
let arguments = (ins
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
AnyTensor:$a,
AnyTensor:$b,
AnyTensor:$c,
AnyTensor:$d,
AnyTensor:$e
[TableGen] Add the `TCopVTEtAreSameAt` PredOpTrait This trait is used for specifying operands at the indices from a given list are with the same element type. -- PiperOrigin-RevId: 246364735
2019-05-03 03:08:17 +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-LABEL: OpJAdaptor::verify
[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: ::llvm::is_splat(::llvm::map_range(
// CHECK-SAME: ::mlir::ArrayRef<unsigned>({0, 2, 3}),
[mlir][NFC] Replace mlir/Support/Functional.h with llvm equivalents. Summary: Functional.h contains many different methods that have a direct, and more efficient, equivalent in LLVM. This revision replaces all usages with the LLVM equivalent, and removes the header. This is part of larger cleanup, pr45513, merging MLIR support facilities into LLVM. Differential Revision: https://reviews.llvm.org/D78053
2020-04-14 05:07:38 +08:00
// CHECK-SAME: [this](unsigned i) { return getElementTypeOrSelf(this->getOperand(i)); }))
[mlir] Add verify method to adaptor This allows verifying op-indepent attributes (e.g., attributes that do not require the op to have been created) before constructing an operation. These include checking whether required attributes are defined or constraints on attributes (such as I32 attribute). This is not perfect (e.g., if one had a disjunctive constraint where one part relied on the op and the other doesn't, then this would not try and extract the op independent from the op dependent). The next step is to move these out to a trait that could be verified earlier than in the generated method. The first use case is for inferring the return type while constructing the op. At that point you don't have an Operation yet and that ends up in one having to duplicate the same checks, e.g., verify that attribute A is defined before querying A in shape function which requires that duplication. Instead this allows one to invoke a method to verify all the traits and, if this is checked first during verification, then all other traits could use attributes knowing they have been verified. It is a little bit funny to have these on the adaptor, but I see the adaptor as a place to collect information about the op before the op is constructed (e.g., avoiding stringly typed accessors, verifying what is possible to verify before the op is constructed) while being cheap to use even with constructed op (so layer of indirection between the op constructed/being constructed). And from that point of view it made sense to me. Differential Revision: https://reviews.llvm.org/D80842
2020-06-06 00:47:37 +08:00
// CHECK: "failed to verify that operands indexed at 0, 2, 3 should all have the same type"
Add utility to accept any tensor type. -- PiperOrigin-RevId: 247264423
2019-05-09 03:18:19 +08:00
def OpK : NS_Op<"op_for_AnyTensorOf", []> {
Clean up container type names in OpBase Establish the following convention: 1. Container class types end in "Of" (e.g. TensorOf) and take a list of allowed types. 2. An X container where only a single type is allowed is called TypeX (e.g. I32Tensor). 3. An X container where any type is allowed is called AnyX (e.g. AnyTensor). -- PiperOrigin-RevId: 249281018
2019-05-22 01:45:30 +08:00
let arguments = (ins TensorOf<[F32, I32]>:$x);
Add utility to accept any tensor type. -- PiperOrigin-RevId: 247264423
2019-05-09 03:18:19 +08:00
}
// CHECK-LABEL: OpK::verify
[mlir][ODS] Add support for optional operands and results with a new Optional directive. Summary: This revision adds support for specifying operands or results as "optional". This is a special case of variadic where the number of elements is either 0 or 1. Operands and results of this kind will have accessors generated using Value instead of the range types, making it more natural to interface with. Differential Revision: https://reviews.llvm.org/D77863
2020-04-11 05:11:45 +08:00
// CHECK: auto valueGroup0 = getODSOperands(0);
[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: for (::mlir::Value v : valueGroup0) {
// CHECK: if (!(((v.getType().isa<::mlir::TensorType>())) && (((v.getType().cast<::mlir::ShapedType>().getElementType().isF32())) || ((v.getType().cast<::mlir::ShapedType>().getElementType().isSignlessInteger(32))))))