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-format-spec.td

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

524 lines
22 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-decls -asmformat-error-is-fatal=false -I %S/../../include %s -o=%t 2>&1 | FileCheck %s
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
// This file contains tests for the specification of the declarative op format.
include "mlir/IR/OpBase.td"
def TestDialect : Dialect {
let name = "test";
}
[mlir] Initial support for type constraints in the declarative assembly format Summary: This revision add support for accepting a few type constraints, e.g. AllTypesMatch, when inferring types for operands and results. This is used to remove the c++ parsers for several additional operations. Differential Revision: https://reviews.llvm.org/D73735
2020-02-04 13:52:38 +08:00
class TestFormat_Op<string name, string fmt, list<OpTrait> traits = []>
: Op<TestDialect, name, traits> {
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
let assemblyFormat = fmt;
}
//===----------------------------------------------------------------------===//
// Directives
//===----------------------------------------------------------------------===//
//===----------------------------------------------------------------------===//
// attr-dict
[MLIR] Add note for file-line numbers in tablegen errors for assembly formats Error messages for the custom assembly format are difficult to understand because there are no line numbers. This happens because the assembly format is parsed as a standalone line, separate from it's parent file, with no useful location information. Fixing this properly probably requires quite a bit of invasive plumbing through the SourceMgr, similar to how included files are handled This proposal is a less invasive short term solution. When generating an error message we generate an additional note which at least properly describes the operation definition the error occured in, if not the actual line number of the assemblyFormat definition. A typical message is like: error: type of operand #0, named 'operand', is not buildable and a buildable type cannot be inferred $operand type($result) attr-dict ^ /src/llvm-project/mlir/test/mlir-tblgen/op-format-spec.td:296:1: note: in custom assembly format for this operation def ZCoverageInvalidC : TestFormat_Op<"variable_invalid_c", [{ ^ note: suggest adding a type constraint to the operation or adding a 'type($operand)' directive to the custom assembly format $operand type($result) attr-dict ^ Differential Revision: https://reviews.llvm.org/D77488
2020-04-05 13:54:35 +08:00
// CHECK: error: 'attr-dict' directive not found
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
def DirectiveAttrDictInvalidA : TestFormat_Op<"attrdict_invalid_a", [{
}]>;
// CHECK: error: 'attr-dict' directive has already been seen
def DirectiveAttrDictInvalidB : TestFormat_Op<"attrdict_invalid_b", [{
attr-dict attr-dict
}]>;
[mlir][DeclarativeParser] Add an 'attr-dict-with-keyword' directive This matches the '(print|parse)OptionalAttrDictWithKeyword' functionality provided by the assembly parser/printer. Differential Revision: https://reviews.llvm.org/D74682
2020-02-22 05:19:26 +08:00
// CHECK: error: 'attr-dict' directive has already been seen
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
def DirectiveAttrDictInvalidC : TestFormat_Op<"attrdict_invalid_c", [{
[mlir][DeclarativeParser] Add an 'attr-dict-with-keyword' directive This matches the '(print|parse)OptionalAttrDictWithKeyword' functionality provided by the assembly parser/printer. Differential Revision: https://reviews.llvm.org/D74682
2020-02-22 05:19:26 +08:00
attr-dict attr-dict-with-keyword
}]>;
// CHECK: error: 'attr-dict' directive can only be used as a top-level directive
def DirectiveAttrDictInvalidD : TestFormat_Op<"attrdict_invalid_d", [{
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
type(attr-dict)
}]>;
// CHECK-NOT: error
[mlir][DeclarativeParser] Add an 'attr-dict-with-keyword' directive This matches the '(print|parse)OptionalAttrDictWithKeyword' functionality provided by the assembly parser/printer. Differential Revision: https://reviews.llvm.org/D74682
2020-02-22 05:19:26 +08:00
def DirectiveAttrDictValidA : TestFormat_Op<"attrdict_valid_a", [{
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
attr-dict
}]>;
[mlir][DeclarativeParser] Add an 'attr-dict-with-keyword' directive This matches the '(print|parse)OptionalAttrDictWithKeyword' functionality provided by the assembly parser/printer. Differential Revision: https://reviews.llvm.org/D74682
2020-02-22 05:19:26 +08:00
def DirectiveAttrDictValidB : TestFormat_Op<"attrdict_valid_b", [{
attr-dict-with-keyword
}]>;
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
[mlir][OpFormatGen] Add support for specifiy "custom" directives. This revision adds support for custom directives to the declarative assembly format. This allows for users to use C++ for printing and parsing subsections of an otherwise declaratively specified format. The custom directive is structured as follows: ``` custom-directive ::= `custom` `<` UserDirective `>` `(` Params `)` ``` `user-directive` is used as a suffix when this directive is used during printing and parsing. When parsing, `parseUserDirective` will be invoked. When printing, `printUserDirective` will be invoked. The first parameter to these methods must be a reference to either the OpAsmParser, or OpAsmPrinter. The type of rest of the parameters is dependent on the `Params` specified in the assembly format. Differential Revision: https://reviews.llvm.org/D84719
2020-09-01 03:33:36 +08:00
//===----------------------------------------------------------------------===//
// custom
// CHECK: error: expected '<' before custom directive name
def DirectiveCustomInvalidA : TestFormat_Op<"custom_invalid_a", [{
custom(
}]>;
// CHECK: error: expected custom directive name identifier
def DirectiveCustomInvalidB : TestFormat_Op<"custom_invalid_b", [{
custom<>
}]>;
// CHECK: error: expected '>' after custom directive name
def DirectiveCustomInvalidC : TestFormat_Op<"custom_invalid_c", [{
custom<MyDirective(
}]>;
// CHECK: error: expected '(' before custom directive parameters
def DirectiveCustomInvalidD : TestFormat_Op<"custom_invalid_d", [{
custom<MyDirective>)
}]>;
// CHECK: error: only variables and types may be used as parameters to a custom directive
def DirectiveCustomInvalidE : TestFormat_Op<"custom_invalid_e", [{
custom<MyDirective>(operands)
}]>;
// CHECK: error: expected ')' after custom directive parameters
def DirectiveCustomInvalidF : TestFormat_Op<"custom_invalid_f", [{
custom<MyDirective>($operand<
}]>, Arguments<(ins I64:$operand)>;
// CHECK: error: type directives within a custom directive may only refer to variables
def DirectiveCustomInvalidH : TestFormat_Op<"custom_invalid_h", [{
custom<MyDirective>(type(operands))
}]>;
// CHECK-NOT: error
def DirectiveCustomValidA : TestFormat_Op<"custom_valid_a", [{
custom<MyDirective>($operand) attr-dict
}]>, Arguments<(ins Optional<I64>:$operand)>;
def DirectiveCustomValidB : TestFormat_Op<"custom_valid_b", [{
custom<MyDirective>($operand, type($operand), type($result)) attr-dict
}]>, Arguments<(ins I64:$operand)>, Results<(outs I64:$result)>;
def DirectiveCustomValidC : TestFormat_Op<"custom_valid_c", [{
custom<MyDirective>($attr) attr-dict
}]>, Arguments<(ins I64Attr:$attr)>;
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
//===----------------------------------------------------------------------===//
// functional-type
// CHECK: error: 'functional-type' is only valid as a top-level directive
def DirectiveFunctionalTypeInvalidA : TestFormat_Op<"functype_invalid_a", [{
functional-type(functional-type)
}]>;
// CHECK: error: expected '(' before argument list
def DirectiveFunctionalTypeInvalidB : TestFormat_Op<"functype_invalid_b", [{
functional-type
}]>;
[mlir][DeclarativeParser] Add basic support for optional groups in the assembly format. When operations have optional attributes, or optional operands(i.e. empty variadic operands), the assembly format often has an optional section to represent these arguments. This revision adds basic support for defining an "optional group" in the assembly format to support this. An optional group is defined by wrapping a set of elements in `()` followed by `?` and requires the following: * The first element of the group must be either a literal or an operand argument. - This is because the first element must be optionally parsable. * There must be exactly one argument variable within the group that is marked as the anchor of the group. The anchor is the element whose presence controls whether the group should be printed/parsed. An element is marked as the anchor by adding a trailing `^`. * The group must only contain literals, variables, and type directives. - Any attribute variables may be used, but only optional attributes can be marked as the anchor. - Only variadic, i.e. optional, operand arguments can be used. - The elements of a type directive must be defined within the same optional group. An example of this can be seen with the assembly format for ReturnOp, which has a variadic number of operands. ``` def ReturnOp : ... { let arguments = (ins Variadic<AnyType>:$operands); // We only print the operands+types if there are a non-zero number // of operands. let assemblyFormat = "attr-dict ($operands^ `:` type($operands))?"; } ``` Differential Revision: https://reviews.llvm.org/D74681
2020-02-22 05:19:15 +08:00
// CHECK: error: expected directive, literal, variable, or optional group
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
def DirectiveFunctionalTypeInvalidC : TestFormat_Op<"functype_invalid_c", [{
functional-type(
}]>;
// CHECK: error: expected ',' after inputs argument
def DirectiveFunctionalTypeInvalidD : TestFormat_Op<"functype_invalid_d", [{
functional-type(operands
}]>;
[mlir][DeclarativeParser] Add basic support for optional groups in the assembly format. When operations have optional attributes, or optional operands(i.e. empty variadic operands), the assembly format often has an optional section to represent these arguments. This revision adds basic support for defining an "optional group" in the assembly format to support this. An optional group is defined by wrapping a set of elements in `()` followed by `?` and requires the following: * The first element of the group must be either a literal or an operand argument. - This is because the first element must be optionally parsable. * There must be exactly one argument variable within the group that is marked as the anchor of the group. The anchor is the element whose presence controls whether the group should be printed/parsed. An element is marked as the anchor by adding a trailing `^`. * The group must only contain literals, variables, and type directives. - Any attribute variables may be used, but only optional attributes can be marked as the anchor. - Only variadic, i.e. optional, operand arguments can be used. - The elements of a type directive must be defined within the same optional group. An example of this can be seen with the assembly format for ReturnOp, which has a variadic number of operands. ``` def ReturnOp : ... { let arguments = (ins Variadic<AnyType>:$operands); // We only print the operands+types if there are a non-zero number // of operands. let assemblyFormat = "attr-dict ($operands^ `:` type($operands))?"; } ``` Differential Revision: https://reviews.llvm.org/D74681
2020-02-22 05:19:15 +08:00
// CHECK: error: expected directive, literal, variable, or optional group
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
def DirectiveFunctionalTypeInvalidE : TestFormat_Op<"functype_invalid_e", [{
functional-type(operands,
}]>;
// CHECK: error: expected ')' after argument list
def DirectiveFunctionalTypeInvalidF : TestFormat_Op<"functype_invalid_f", [{
functional-type(operands, results
}]>;
// CHECK-NOT: error
def DirectiveFunctionalTypeValid : TestFormat_Op<"functype_invalid_a", [{
functional-type(operands, results) attr-dict
}]>;
//===----------------------------------------------------------------------===//
// operands
// CHECK: error: 'operands' directive creates overlap in format
def DirectiveOperandsInvalidA : TestFormat_Op<"operands_invalid_a", [{
operands operands
}]>;
// CHECK: error: 'operands' directive creates overlap in format
def DirectiveOperandsInvalidB : TestFormat_Op<"operands_invalid_b", [{
$operand operands
}]>, Arguments<(ins I64:$operand)>;
// CHECK-NOT: error:
def DirectiveOperandsValid : TestFormat_Op<"operands_valid", [{
operands attr-dict
}]>;
[mlir][OpFormatGen] Add initial support for regions in the custom op assembly format This adds some initial support for regions and does not support formatting the specific arguments of a region. For now this can be achieved by using a custom directive that formats the arguments and then parses the region. Differential Revision: https://reviews.llvm.org/D86760
2020-09-01 03:33:55 +08:00
//===----------------------------------------------------------------------===//
// regions
// CHECK: error: 'regions' directive creates overlap in format
def DirectiveRegionsInvalidA : TestFormat_Op<"regions_invalid_a", [{
regions regions attr-dict
}]>;
// CHECK: error: 'regions' directive creates overlap in format
def DirectiveRegionsInvalidB : TestFormat_Op<"regions_invalid_b", [{
$region regions attr-dict
}]> {
let regions = (region AnyRegion:$region);
}
// CHECK: error: 'regions' is only valid as a top-level directive
def DirectiveRegionsInvalidC : TestFormat_Op<"regions_invalid_c", [{
type(regions)
}]>;
// CHECK-NOT: error:
def DirectiveRegionsValid : TestFormat_Op<"regions_valid", [{
regions attr-dict
}]>;
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
//===----------------------------------------------------------------------===//
// results
// CHECK: error: 'results' directive can not be used as a top-level directive
[mlir][DeclarativeParser] Add support for formatting the successors of an operation. This revision add support for formatting successor variables in a similar way to operands, attributes, etc. Differential Revision: https://reviews.llvm.org/D74789
2020-02-22 05:20:06 +08:00
def DirectiveResultsInvalidA : TestFormat_Op<"results_invalid_a", [{
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
results
}]>;
[mlir][DeclarativeParser] Add support for formatting the successors of an operation. This revision add support for formatting successor variables in a similar way to operands, attributes, etc. Differential Revision: https://reviews.llvm.org/D74789
2020-02-22 05:20:06 +08:00
//===----------------------------------------------------------------------===//
// successors
// CHECK: error: 'successors' is only valid as a top-level directive
def DirectiveSuccessorsInvalidA : TestFormat_Op<"successors_invalid_a", [{
type(successors)
}]>;
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
//===----------------------------------------------------------------------===//
// type
// CHECK: error: expected '(' before argument list
def DirectiveTypeInvalidA : TestFormat_Op<"type_invalid_a", [{
type
}]>;
[mlir][DeclarativeParser] Add basic support for optional groups in the assembly format. When operations have optional attributes, or optional operands(i.e. empty variadic operands), the assembly format often has an optional section to represent these arguments. This revision adds basic support for defining an "optional group" in the assembly format to support this. An optional group is defined by wrapping a set of elements in `()` followed by `?` and requires the following: * The first element of the group must be either a literal or an operand argument. - This is because the first element must be optionally parsable. * There must be exactly one argument variable within the group that is marked as the anchor of the group. The anchor is the element whose presence controls whether the group should be printed/parsed. An element is marked as the anchor by adding a trailing `^`. * The group must only contain literals, variables, and type directives. - Any attribute variables may be used, but only optional attributes can be marked as the anchor. - Only variadic, i.e. optional, operand arguments can be used. - The elements of a type directive must be defined within the same optional group. An example of this can be seen with the assembly format for ReturnOp, which has a variadic number of operands. ``` def ReturnOp : ... { let arguments = (ins Variadic<AnyType>:$operands); // We only print the operands+types if there are a non-zero number // of operands. let assemblyFormat = "attr-dict ($operands^ `:` type($operands))?"; } ``` Differential Revision: https://reviews.llvm.org/D74681
2020-02-22 05:19:15 +08:00
// CHECK: error: expected directive, literal, variable, or optional group
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
def DirectiveTypeInvalidB : TestFormat_Op<"type_invalid_b", [{
type(
}]>;
// CHECK: error: expected ')' after argument list
def DirectiveTypeInvalidC : TestFormat_Op<"type_invalid_c", [{
type(operands
}]>;
// CHECK-NOT: error:
def DirectiveTypeValid : TestFormat_Op<"type_valid", [{
type(operands) attr-dict
}]>;
//===----------------------------------------------------------------------===//
// functional-type/type operands
// CHECK: error: 'type' directive operand expects variable or directive operand
def DirectiveTypeZOperandInvalidA : TestFormat_Op<"type_operand_invalid_a", [{
type(`literal`)
}]>;
// CHECK: error: 'operands' 'type' is already bound
def DirectiveTypeZOperandInvalidB : TestFormat_Op<"type_operand_invalid_b", [{
type(operands) type(operands)
}]>;
// CHECK: error: 'operands' 'type' is already bound
def DirectiveTypeZOperandInvalidC : TestFormat_Op<"type_operand_invalid_c", [{
type($operand) type(operands)
}]>, Arguments<(ins I64:$operand)>;
// CHECK: error: 'type' of 'operand' is already bound
def DirectiveTypeZOperandInvalidD : TestFormat_Op<"type_operand_invalid_d", [{
type(operands) type($operand)
}]>, Arguments<(ins I64:$operand)>;
// CHECK: error: 'type' of 'operand' is already bound
def DirectiveTypeZOperandInvalidE : TestFormat_Op<"type_operand_invalid_e", [{
type($operand) type($operand)
}]>, Arguments<(ins I64:$operand)>;
// CHECK: error: 'results' 'type' is already bound
def DirectiveTypeZOperandInvalidF : TestFormat_Op<"type_operand_invalid_f", [{
type(results) type(results)
}]>;
// CHECK: error: 'results' 'type' is already bound
def DirectiveTypeZOperandInvalidG : TestFormat_Op<"type_operand_invalid_g", [{
type($result) type(results)
}]>, Results<(outs I64:$result)>;
// CHECK: error: 'type' of 'result' is already bound
def DirectiveTypeZOperandInvalidH : TestFormat_Op<"type_operand_invalid_h", [{
type(results) type($result)
}]>, Results<(outs I64:$result)>;
// CHECK: error: 'type' of 'result' is already bound
def DirectiveTypeZOperandInvalidI : TestFormat_Op<"type_operand_invalid_i", [{
type($result) type($result)
}]>, Results<(outs I64:$result)>;
[mlir][Linalg] Evolve named ops to use assembly form and support linalg on tensors. This revision allows representing a reduction at the level of linalg on tensors for named ops. When a structured op has a reduction and returns tensor(s), new conventions are added and documented. As an illustration, the syntax for a `linalg.matmul` writing into a buffer is: ``` linalg.matmul ins(%a, %b : memref<?x?xf32>, tensor<?x?xf32>) outs(%c : memref<?x?xf32>) ``` , whereas the syntax for a `linalg.matmul` returning a new tensor is: ``` %d = linalg.matmul ins(%a, %b : tensor<?x?xf32>, memref<?x?xf32>) init(%c : memref<?x?xf32>) -> tensor<?x?xf32> ``` Other parts of linalg will be extended accordingly to allow mixed buffer/tensor semantics in the presence of reductions.
2020-09-18 18:13:25 +08:00
//===----------------------------------------------------------------------===//
// type_ref
// CHECK: error: 'type_ref' of 'operand' is not bound by a prior 'type' directive
def DirectiveTypeZZTypeRefOperandInvalidC : TestFormat_Op<"type_ref_operand_invalid_c", [{
type_ref($operand) type(operands)
}]>, Arguments<(ins I64:$operand)>;
// CHECK: error: 'operands' 'type_ref' is not bound by a prior 'type' directive
def DirectiveTypeZZTypeRefOperandInvalidD : TestFormat_Op<"type_ref_operand_invalid_d", [{
type_ref(operands) type($operand)
}]>, Arguments<(ins I64:$operand)>;
// CHECK: error: 'type_ref' of 'operand' is not bound by a prior 'type' directive
def DirectiveTypeZZTypeRefOperandInvalidE : TestFormat_Op<"type_ref_operand_invalid_e", [{
type_ref($operand) type($operand)
}]>, Arguments<(ins I64:$operand)>;
// CHECK: error: 'type_ref' of 'result' is not bound by a prior 'type' directive
def DirectiveTypeZZTypeRefOperandInvalidG : TestFormat_Op<"type_ref_operand_invalid_g", [{
type_ref($result) type(results)
}]>, Results<(outs I64:$result)>;
// CHECK: error: 'results' 'type_ref' is not bound by a prior 'type' directive
def DirectiveTypeZZTypeRefOperandInvalidH : TestFormat_Op<"type_ref_operand_invalid_h", [{
type_ref(results) type($result)
}]>, Results<(outs I64:$result)>;
// CHECK: error: 'type_ref' of 'result' is not bound by a prior 'type' directive
def DirectiveTypeZZTypeRefOperandInvalidI : TestFormat_Op<"type_ref_operand_invalid_i", [{
type_ref($result) type($result)
}]>, Results<(outs I64:$result)>;
// CHECK-NOT: error
def DirectiveTypeZZTypeRefOperandB : TestFormat_Op<"type_ref_operand_valid_b", [{
type_ref(operands) attr-dict
}]>;
// CHECK-NOT: error
def DirectiveTypeZZTypeRefOperandD : TestFormat_Op<"type_ref_operand_valid_d", [{
type(operands) type_ref($operand) attr-dict
}]>, Arguments<(ins I64:$operand)>;
// CHECK-NOT: error
def DirectiveTypeZZTypeRefOperandE : TestFormat_Op<"type_ref_operand_valid_e", [{
type($operand) type_ref($operand) attr-dict
}]>, Arguments<(ins I64:$operand)>;
// CHECK-NOT: error
def DirectiveTypeZZTypeRefOperandF : TestFormat_Op<"type_ref_operand_valid_f", [{
type(results) type_ref(results) attr-dict
}]>;
// CHECK-NOT: error
def DirectiveTypeZZTypeRefOperandG : TestFormat_Op<"type_ref_operand_valid_g", [{
type($result) type_ref(results) attr-dict
}]>, Results<(outs I64:$result)>;
// CHECK-NOT: error
def DirectiveTypeZZTypeRefOperandH : TestFormat_Op<"type_ref_operand_valid_h", [{
type(results) type_ref($result) attr-dict
}]>, Results<(outs I64:$result)>;
// CHECK-NOT: error
def DirectiveTypeZZTypeRefOperandI : TestFormat_Op<"type_ref_operand_valid_i", [{
type($result) type_ref($result) attr-dict
}]>, Results<(outs I64:$result)>;
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
// CHECK-NOT: error:
[mlir][Linalg] Evolve named ops to use assembly form and support linalg on tensors. This revision allows representing a reduction at the level of linalg on tensors for named ops. When a structured op has a reduction and returns tensor(s), new conventions are added and documented. As an illustration, the syntax for a `linalg.matmul` writing into a buffer is: ``` linalg.matmul ins(%a, %b : memref<?x?xf32>, tensor<?x?xf32>) outs(%c : memref<?x?xf32>) ``` , whereas the syntax for a `linalg.matmul` returning a new tensor is: ``` %d = linalg.matmul ins(%a, %b : tensor<?x?xf32>, memref<?x?xf32>) init(%c : memref<?x?xf32>) -> tensor<?x?xf32> ``` Other parts of linalg will be extended accordingly to allow mixed buffer/tensor semantics in the presence of reductions.
2020-09-18 18:13:25 +08:00
def DirectiveTypeZZZOperandValid : TestFormat_Op<"type_operand_valid", [{
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
type(operands) type(results) attr-dict
}]>;
//===----------------------------------------------------------------------===//
// Literals
//===----------------------------------------------------------------------===//
// Test all of the valid literals.
// CHECK: error: expected valid literal
def LiteralInvalidA : TestFormat_Op<"literal_invalid_a", [{
`1`
}]>;
// CHECK: error: unexpected end of file in literal
[mlir][DeclarativeParser] Add basic support for optional groups in the assembly format. When operations have optional attributes, or optional operands(i.e. empty variadic operands), the assembly format often has an optional section to represent these arguments. This revision adds basic support for defining an "optional group" in the assembly format to support this. An optional group is defined by wrapping a set of elements in `()` followed by `?` and requires the following: * The first element of the group must be either a literal or an operand argument. - This is because the first element must be optionally parsable. * There must be exactly one argument variable within the group that is marked as the anchor of the group. The anchor is the element whose presence controls whether the group should be printed/parsed. An element is marked as the anchor by adding a trailing `^`. * The group must only contain literals, variables, and type directives. - Any attribute variables may be used, but only optional attributes can be marked as the anchor. - Only variadic, i.e. optional, operand arguments can be used. - The elements of a type directive must be defined within the same optional group. An example of this can be seen with the assembly format for ReturnOp, which has a variadic number of operands. ``` def ReturnOp : ... { let arguments = (ins Variadic<AnyType>:$operands); // We only print the operands+types if there are a non-zero number // of operands. let assemblyFormat = "attr-dict ($operands^ `:` type($operands))?"; } ``` Differential Revision: https://reviews.llvm.org/D74681
2020-02-22 05:19:15 +08:00
// CHECK: error: expected directive, literal, variable, or optional group
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
def LiteralInvalidB : TestFormat_Op<"literal_invalid_b", [{
`
}]>;
// CHECK-NOT: error
def LiteralValid : TestFormat_Op<"literal_valid", [{
`_` `:` `,` `=` `<` `>` `(` `)` `[` `]` `->` `abc$._`
attr-dict
}]>;
[mlir][DeclarativeParser] Add basic support for optional groups in the assembly format. When operations have optional attributes, or optional operands(i.e. empty variadic operands), the assembly format often has an optional section to represent these arguments. This revision adds basic support for defining an "optional group" in the assembly format to support this. An optional group is defined by wrapping a set of elements in `()` followed by `?` and requires the following: * The first element of the group must be either a literal or an operand argument. - This is because the first element must be optionally parsable. * There must be exactly one argument variable within the group that is marked as the anchor of the group. The anchor is the element whose presence controls whether the group should be printed/parsed. An element is marked as the anchor by adding a trailing `^`. * The group must only contain literals, variables, and type directives. - Any attribute variables may be used, but only optional attributes can be marked as the anchor. - Only variadic, i.e. optional, operand arguments can be used. - The elements of a type directive must be defined within the same optional group. An example of this can be seen with the assembly format for ReturnOp, which has a variadic number of operands. ``` def ReturnOp : ... { let arguments = (ins Variadic<AnyType>:$operands); // We only print the operands+types if there are a non-zero number // of operands. let assemblyFormat = "attr-dict ($operands^ `:` type($operands))?"; } ``` Differential Revision: https://reviews.llvm.org/D74681
2020-02-22 05:19:15 +08:00
//===----------------------------------------------------------------------===//
// Optional Groups
//===----------------------------------------------------------------------===//
// CHECK: error: optional groups can only be used as top-level elements
def OptionalInvalidA : TestFormat_Op<"optional_invalid_a", [{
type(($attr^)?) attr-dict
}]>, Arguments<(ins OptionalAttr<I64Attr>:$attr)>;
// CHECK: error: expected directive, literal, variable, or optional group
def OptionalInvalidB : TestFormat_Op<"optional_invalid_b", [{
() attr-dict
}]>, Arguments<(ins OptionalAttr<I64Attr>:$attr)>;
// CHECK: error: optional group specified no anchor element
def OptionalInvalidC : TestFormat_Op<"optional_invalid_c", [{
($attr)? attr-dict
}]>, Arguments<(ins OptionalAttr<I64Attr>:$attr)>;
[mlir][OpFormatGen] Add initial support for regions in the custom op assembly format This adds some initial support for regions and does not support formatting the specific arguments of a region. For now this can be achieved by using a custom directive that formats the arguments and then parses the region. Differential Revision: https://reviews.llvm.org/D86760
2020-09-01 03:33:55 +08:00
// CHECK: error: first element of an operand group must be an attribute, literal, operand, or region
[mlir][DeclarativeParser] Add basic support for optional groups in the assembly format. When operations have optional attributes, or optional operands(i.e. empty variadic operands), the assembly format often has an optional section to represent these arguments. This revision adds basic support for defining an "optional group" in the assembly format to support this. An optional group is defined by wrapping a set of elements in `()` followed by `?` and requires the following: * The first element of the group must be either a literal or an operand argument. - This is because the first element must be optionally parsable. * There must be exactly one argument variable within the group that is marked as the anchor of the group. The anchor is the element whose presence controls whether the group should be printed/parsed. An element is marked as the anchor by adding a trailing `^`. * The group must only contain literals, variables, and type directives. - Any attribute variables may be used, but only optional attributes can be marked as the anchor. - Only variadic, i.e. optional, operand arguments can be used. - The elements of a type directive must be defined within the same optional group. An example of this can be seen with the assembly format for ReturnOp, which has a variadic number of operands. ``` def ReturnOp : ... { let arguments = (ins Variadic<AnyType>:$operands); // We only print the operands+types if there are a non-zero number // of operands. let assemblyFormat = "attr-dict ($operands^ `:` type($operands))?"; } ``` Differential Revision: https://reviews.llvm.org/D74681
2020-02-22 05:19:15 +08:00
def OptionalInvalidD : TestFormat_Op<"optional_invalid_d", [{
[mlir] Add support for parsing optional Attribute values. This adds a `parseOptionalAttribute` method to the OpAsmParser that allows for parsing optional attributes, in a similar fashion to how optional types are parsed. This also enables the use of attribute values as the first element of an assembly format optional group. Differential Revision: https://reviews.llvm.org/D83712
2020-07-15 04:14:14 +08:00
(type($operand) $operand^)? attr-dict
}]>, Arguments<(ins Optional<I64>:$operand)>;
[mlir][DeclarativeParser] Add basic support for optional groups in the assembly format. When operations have optional attributes, or optional operands(i.e. empty variadic operands), the assembly format often has an optional section to represent these arguments. This revision adds basic support for defining an "optional group" in the assembly format to support this. An optional group is defined by wrapping a set of elements in `()` followed by `?` and requires the following: * The first element of the group must be either a literal or an operand argument. - This is because the first element must be optionally parsable. * There must be exactly one argument variable within the group that is marked as the anchor of the group. The anchor is the element whose presence controls whether the group should be printed/parsed. An element is marked as the anchor by adding a trailing `^`. * The group must only contain literals, variables, and type directives. - Any attribute variables may be used, but only optional attributes can be marked as the anchor. - Only variadic, i.e. optional, operand arguments can be used. - The elements of a type directive must be defined within the same optional group. An example of this can be seen with the assembly format for ReturnOp, which has a variadic number of operands. ``` def ReturnOp : ... { let arguments = (ins Variadic<AnyType>:$operands); // We only print the operands+types if there are a non-zero number // of operands. let assemblyFormat = "attr-dict ($operands^ `:` type($operands))?"; } ``` Differential Revision: https://reviews.llvm.org/D74681
2020-02-22 05:19:15 +08:00
// CHECK: error: type directive can only refer to variables within the optional group
def OptionalInvalidE : TestFormat_Op<"optional_invalid_e", [{
(`,` $attr^ type(operands))? attr-dict
}]>, Arguments<(ins OptionalAttr<I64Attr>:$attr)>;
// CHECK: error: only one element can be marked as the anchor of an optional group
def OptionalInvalidF : TestFormat_Op<"optional_invalid_f", [{
($attr^ $attr2^) attr-dict
}]>, Arguments<(ins OptionalAttr<I64Attr>:$attr, OptionalAttr<I64Attr>:$attr2)>;
// CHECK: error: only optional attributes can be used to anchor an optional group
def OptionalInvalidG : TestFormat_Op<"optional_invalid_g", [{
($attr^) attr-dict
}]>, Arguments<(ins I64Attr:$attr)>;
[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: error: only variable length operands can be used within an optional group
[mlir][DeclarativeParser] Add basic support for optional groups in the assembly format. When operations have optional attributes, or optional operands(i.e. empty variadic operands), the assembly format often has an optional section to represent these arguments. This revision adds basic support for defining an "optional group" in the assembly format to support this. An optional group is defined by wrapping a set of elements in `()` followed by `?` and requires the following: * The first element of the group must be either a literal or an operand argument. - This is because the first element must be optionally parsable. * There must be exactly one argument variable within the group that is marked as the anchor of the group. The anchor is the element whose presence controls whether the group should be printed/parsed. An element is marked as the anchor by adding a trailing `^`. * The group must only contain literals, variables, and type directives. - Any attribute variables may be used, but only optional attributes can be marked as the anchor. - Only variadic, i.e. optional, operand arguments can be used. - The elements of a type directive must be defined within the same optional group. An example of this can be seen with the assembly format for ReturnOp, which has a variadic number of operands. ``` def ReturnOp : ... { let arguments = (ins Variadic<AnyType>:$operands); // We only print the operands+types if there are a non-zero number // of operands. let assemblyFormat = "attr-dict ($operands^ `:` type($operands))?"; } ``` Differential Revision: https://reviews.llvm.org/D74681
2020-02-22 05:19:15 +08:00
def OptionalInvalidH : TestFormat_Op<"optional_invalid_h", [{
($arg^) attr-dict
}]>, Arguments<(ins I64:$arg)>;
// CHECK: error: only variables can be used to anchor an optional group
def OptionalInvalidI : TestFormat_Op<"optional_invalid_i", [{
($arg type($arg)^) attr-dict
}]>, Arguments<(ins Variadic<I64>:$arg)>;
// CHECK: error: only literals, types, and variables can be used within an optional group
def OptionalInvalidJ : TestFormat_Op<"optional_invalid_j", [{
(attr-dict)
}]>;
// CHECK: error: expected '?' after optional group
def OptionalInvalidK : TestFormat_Op<"optional_invalid_k", [{
($arg^)
}]>, Arguments<(ins Variadic<I64>:$arg)>;
[mlir][OpFormatGen] Add support for specifiy "custom" directives. This revision adds support for custom directives to the declarative assembly format. This allows for users to use C++ for printing and parsing subsections of an otherwise declaratively specified format. The custom directive is structured as follows: ``` custom-directive ::= `custom` `<` UserDirective `>` `(` Params `)` ``` `user-directive` is used as a suffix when this directive is used during printing and parsing. When parsing, `parseUserDirective` will be invoked. When printing, `printUserDirective` will be invoked. The first parameter to these methods must be a reference to either the OpAsmParser, or OpAsmPrinter. The type of rest of the parameters is dependent on the `Params` specified in the assembly format. Differential Revision: https://reviews.llvm.org/D84719
2020-09-01 03:33:36 +08:00
// CHECK: error: only variables can be used to anchor an optional group
def OptionalInvalidL : TestFormat_Op<"optional_invalid_l", [{
(custom<MyDirective>($arg)^)?
}]>, Arguments<(ins I64:$arg)>;
[mlir][DeclarativeParser] Add basic support for optional groups in the assembly format. When operations have optional attributes, or optional operands(i.e. empty variadic operands), the assembly format often has an optional section to represent these arguments. This revision adds basic support for defining an "optional group" in the assembly format to support this. An optional group is defined by wrapping a set of elements in `()` followed by `?` and requires the following: * The first element of the group must be either a literal or an operand argument. - This is because the first element must be optionally parsable. * There must be exactly one argument variable within the group that is marked as the anchor of the group. The anchor is the element whose presence controls whether the group should be printed/parsed. An element is marked as the anchor by adding a trailing `^`. * The group must only contain literals, variables, and type directives. - Any attribute variables may be used, but only optional attributes can be marked as the anchor. - Only variadic, i.e. optional, operand arguments can be used. - The elements of a type directive must be defined within the same optional group. An example of this can be seen with the assembly format for ReturnOp, which has a variadic number of operands. ``` def ReturnOp : ... { let arguments = (ins Variadic<AnyType>:$operands); // We only print the operands+types if there are a non-zero number // of operands. let assemblyFormat = "attr-dict ($operands^ `:` type($operands))?"; } ``` Differential Revision: https://reviews.llvm.org/D74681
2020-02-22 05:19:15 +08:00
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
//===----------------------------------------------------------------------===//
// Variables
//===----------------------------------------------------------------------===//
[mlir][OpFormatGen] Add initial support for regions in the custom op assembly format This adds some initial support for regions and does not support formatting the specific arguments of a region. For now this can be achieved by using a custom directive that formats the arguments and then parses the region. Differential Revision: https://reviews.llvm.org/D86760
2020-09-01 03:33:55 +08:00
// CHECK: error: expected variable to refer to an argument, region, result, or successor
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
def VariableInvalidA : TestFormat_Op<"variable_invalid_a", [{
$unknown_arg attr-dict
}]>;
// CHECK: error: attribute 'attr' is already bound
def VariableInvalidB : TestFormat_Op<"variable_invalid_b", [{
$attr $attr attr-dict
}]>, Arguments<(ins I64Attr:$attr)>;
// CHECK: error: operand 'operand' is already bound
def VariableInvalidC : TestFormat_Op<"variable_invalid_c", [{
$operand $operand attr-dict
}]>, Arguments<(ins I64:$operand)>;
// CHECK: error: operand 'operand' is already bound
def VariableInvalidD : TestFormat_Op<"variable_invalid_d", [{
operands $operand attr-dict
}]>, Arguments<(ins I64:$operand)>;
// CHECK: error: results can not be used at the top level
def VariableInvalidE : TestFormat_Op<"variable_invalid_e", [{
$result attr-dict
}]>, Results<(outs I64:$result)>;
[mlir][DeclarativeParser] Add support for formatting the successors of an operation. This revision add support for formatting successor variables in a similar way to operands, attributes, etc. Differential Revision: https://reviews.llvm.org/D74789
2020-02-22 05:20:06 +08:00
// CHECK: error: successor 'successor' is already bound
def VariableInvalidF : TestFormat_Op<"variable_invalid_f", [{
$successor $successor attr-dict
}]> {
let successors = (successor AnySuccessor:$successor);
}
// CHECK: error: successor 'successor' is already bound
def VariableInvalidG : TestFormat_Op<"variable_invalid_g", [{
successors $successor attr-dict
}]> {
let successors = (successor AnySuccessor:$successor);
}
[mlir][DeclarativeParser] Emit an error if a `:` follows an attribute with a non-constant type. Summary: The attribute grammar includes an optional trailing colon type, so for attributes without a constant buildable type this will generally lead to unexpected and undesired behavior. Given that, it's better to just error out on these cases. Differential Revision: https://reviews.llvm.org/D77293
2020-04-04 10:20:33 +08:00
// CHECK: error: format ambiguity caused by `:` literal found after attribute `attr` which does not have a buildable type
def VariableInvalidH : TestFormat_Op<"variable_invalid_h", [{
$attr `:` attr-dict
}]>, Arguments<(ins ElementsAttr:$attr)>;
// CHECK: error: format ambiguity caused by `:` literal found after attribute `attr` which does not have a buildable type
def VariableInvalidI : TestFormat_Op<"variable_invalid_i", [{
(`foo` $attr^)? `:` attr-dict
}]>, Arguments<(ins OptionalAttr<ElementsAttr>:$attr)>;
[mlir][OpFormatGen] Add initial support for regions in the custom op assembly format This adds some initial support for regions and does not support formatting the specific arguments of a region. For now this can be achieved by using a custom directive that formats the arguments and then parses the region. Differential Revision: https://reviews.llvm.org/D86760
2020-09-01 03:33:55 +08:00
// CHECK: error: region 'region' is already bound
[mlir][DeclarativeParser] Emit an error if a `:` follows an attribute with a non-constant type. Summary: The attribute grammar includes an optional trailing colon type, so for attributes without a constant buildable type this will generally lead to unexpected and undesired behavior. Given that, it's better to just error out on these cases. Differential Revision: https://reviews.llvm.org/D77293
2020-04-04 10:20:33 +08:00
def VariableInvalidJ : TestFormat_Op<"variable_invalid_j", [{
[mlir][OpFormatGen] Add initial support for regions in the custom op assembly format This adds some initial support for regions and does not support formatting the specific arguments of a region. For now this can be achieved by using a custom directive that formats the arguments and then parses the region. Differential Revision: https://reviews.llvm.org/D86760
2020-09-01 03:33:55 +08:00
$region $region attr-dict
}]> {
let regions = (region AnyRegion:$region);
}
// CHECK: error: region 'region' is already bound
def VariableInvalidK : TestFormat_Op<"variable_invalid_K", [{
regions $region attr-dict
}]> {
let regions = (region AnyRegion:$region);
}
// CHECK: error: regions can only be used at the top level
def VariableInvalidL : TestFormat_Op<"variable_invalid_l", [{
type($region)
}]> {
let regions = (region AnyRegion:$region);
}
// CHECK: error: region #0, named 'region', not found
def VariableInvalidM : TestFormat_Op<"variable_invalid_m", [{
attr-dict
}]> {
let regions = (region AnyRegion:$region);
}
// CHECK-NOT: error:
def VariableValidA : TestFormat_Op<"variable_valid_a", [{
[mlir][DeclarativeParser] Emit an error if a `:` follows an attribute with a non-constant type. Summary: The attribute grammar includes an optional trailing colon type, so for attributes without a constant buildable type this will generally lead to unexpected and undesired behavior. Given that, it's better to just error out on these cases. Differential Revision: https://reviews.llvm.org/D77293
2020-04-04 10:20:33 +08:00
$attr `:` attr-dict
}]>, Arguments<(ins OptionalAttr<I1Attr>:$attr)>;
[mlir][OpFormatGen] Add initial support for regions in the custom op assembly format This adds some initial support for regions and does not support formatting the specific arguments of a region. For now this can be achieved by using a custom directive that formats the arguments and then parses the region. Differential Revision: https://reviews.llvm.org/D86760
2020-09-01 03:33:55 +08:00
def VariableValidB : TestFormat_Op<"variable_valid_b", [{
[mlir][DeclarativeParser] Emit an error if a `:` follows an attribute with a non-constant type. Summary: The attribute grammar includes an optional trailing colon type, so for attributes without a constant buildable type this will generally lead to unexpected and undesired behavior. Given that, it's better to just error out on these cases. Differential Revision: https://reviews.llvm.org/D77293
2020-04-04 10:20:33 +08:00
(`foo` $attr^)? `:` attr-dict
}]>, Arguments<(ins OptionalAttr<I1Attr>:$attr)>;
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
//===----------------------------------------------------------------------===//
// Coverage Checks
//===----------------------------------------------------------------------===//
[MLIR] Cleanup mlir-tblgen error messages for custom assembly formats. The messages are somewhat cryptic, since they are not complete sentences, include lots of ambiguous words, like 'format' which are hard to parse, and include names from the users code which may, or may not make sense in the context of the message. Start to clean this up and provide some guidance for fixes. Also, add a test for one of the messages which didn't have a test at all. Differential Revision: https://reviews.llvm.org/D77449
2020-04-04 09:17:51 +08:00
// CHECK: error: type of result #0, named 'result', is not buildable and a buildable type cannot be inferred
// CHECK: note: suggest adding a type constraint to the operation or adding a 'type($result)' directive to the custom assembly format
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
def ZCoverageInvalidA : TestFormat_Op<"variable_invalid_a", [{
attr-dict
}]>, Arguments<(ins AnyMemRef:$operand)>, Results<(outs AnyMemRef:$result)>;
[MLIR] Add note for file-line numbers in tablegen errors for assembly formats Error messages for the custom assembly format are difficult to understand because there are no line numbers. This happens because the assembly format is parsed as a standalone line, separate from it's parent file, with no useful location information. Fixing this properly probably requires quite a bit of invasive plumbing through the SourceMgr, similar to how included files are handled This proposal is a less invasive short term solution. When generating an error message we generate an additional note which at least properly describes the operation definition the error occured in, if not the actual line number of the assemblyFormat definition. A typical message is like: error: type of operand #0, named 'operand', is not buildable and a buildable type cannot be inferred $operand type($result) attr-dict ^ /src/llvm-project/mlir/test/mlir-tblgen/op-format-spec.td:296:1: note: in custom assembly format for this operation def ZCoverageInvalidC : TestFormat_Op<"variable_invalid_c", [{ ^ note: suggest adding a type constraint to the operation or adding a 'type($operand)' directive to the custom assembly format $operand type($result) attr-dict ^ Differential Revision: https://reviews.llvm.org/D77488
2020-04-05 13:54:35 +08:00
// CHECK: error: operand #0, named 'operand', not found
[MLIR] Cleanup mlir-tblgen error messages for custom assembly formats. The messages are somewhat cryptic, since they are not complete sentences, include lots of ambiguous words, like 'format' which are hard to parse, and include names from the users code which may, or may not make sense in the context of the message. Start to clean this up and provide some guidance for fixes. Also, add a test for one of the messages which didn't have a test at all. Differential Revision: https://reviews.llvm.org/D77449
2020-04-04 09:17:51 +08:00
// CHECK: note: suggest adding a '$operand' directive to the custom assembly format
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
def ZCoverageInvalidB : TestFormat_Op<"variable_invalid_b", [{
type($result) attr-dict
}]>, Arguments<(ins AnyMemRef:$operand)>, Results<(outs AnyMemRef:$result)>;
[MLIR] Cleanup mlir-tblgen error messages for custom assembly formats. The messages are somewhat cryptic, since they are not complete sentences, include lots of ambiguous words, like 'format' which are hard to parse, and include names from the users code which may, or may not make sense in the context of the message. Start to clean this up and provide some guidance for fixes. Also, add a test for one of the messages which didn't have a test at all. Differential Revision: https://reviews.llvm.org/D77449
2020-04-04 09:17:51 +08:00
// CHECK: error: type of operand #0, named 'operand', is not buildable and a buildable type cannot be inferred
// CHECK: note: suggest adding a type constraint to the operation or adding a 'type($operand)' directive to the custom assembly format
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
def ZCoverageInvalidC : TestFormat_Op<"variable_invalid_c", [{
$operand type($result) attr-dict
}]>, Arguments<(ins AnyMemRef:$operand)>, Results<(outs AnyMemRef:$result)>;
[MLIR] Cleanup mlir-tblgen error messages for custom assembly formats. The messages are somewhat cryptic, since they are not complete sentences, include lots of ambiguous words, like 'format' which are hard to parse, and include names from the users code which may, or may not make sense in the context of the message. Start to clean this up and provide some guidance for fixes. Also, add a test for one of the messages which didn't have a test at all. Differential Revision: https://reviews.llvm.org/D77449
2020-04-04 09:17:51 +08:00
// CHECK: error: type of operand #0, named 'operand', is not buildable and a buildable type cannot be inferred
// CHECK: note: suggest adding a type constraint to the operation or adding a 'type($operand)' directive to the custom assembly format
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
def ZCoverageInvalidD : TestFormat_Op<"variable_invalid_d", [{
operands attr-dict
}]>, Arguments<(ins Variadic<I64>:$operand)>;
[MLIR] Cleanup mlir-tblgen error messages for custom assembly formats. The messages are somewhat cryptic, since they are not complete sentences, include lots of ambiguous words, like 'format' which are hard to parse, and include names from the users code which may, or may not make sense in the context of the message. Start to clean this up and provide some guidance for fixes. Also, add a test for one of the messages which didn't have a test at all. Differential Revision: https://reviews.llvm.org/D77449
2020-04-04 09:17:51 +08:00
// CHECK: error: type of result #0, named 'result', is not buildable and a buildable type cannot be inferred
// CHECK: note: suggest adding a type constraint to the operation or adding a 'type($result)' directive to the custom assembly format
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
def ZCoverageInvalidE : TestFormat_Op<"variable_invalid_e", [{
attr-dict
}]>, Results<(outs Variadic<I64>:$result)>;
[MLIR] Add note for file-line numbers in tablegen errors for assembly formats Error messages for the custom assembly format are difficult to understand because there are no line numbers. This happens because the assembly format is parsed as a standalone line, separate from it's parent file, with no useful location information. Fixing this properly probably requires quite a bit of invasive plumbing through the SourceMgr, similar to how included files are handled This proposal is a less invasive short term solution. When generating an error message we generate an additional note which at least properly describes the operation definition the error occured in, if not the actual line number of the assemblyFormat definition. A typical message is like: error: type of operand #0, named 'operand', is not buildable and a buildable type cannot be inferred $operand type($result) attr-dict ^ /src/llvm-project/mlir/test/mlir-tblgen/op-format-spec.td:296:1: note: in custom assembly format for this operation def ZCoverageInvalidC : TestFormat_Op<"variable_invalid_c", [{ ^ note: suggest adding a type constraint to the operation or adding a 'type($operand)' directive to the custom assembly format $operand type($result) attr-dict ^ Differential Revision: https://reviews.llvm.org/D77488
2020-04-05 13:54:35 +08:00
// CHECK: error: successor #0, named 'successor', not found
[MLIR] Cleanup mlir-tblgen error messages for custom assembly formats. The messages are somewhat cryptic, since they are not complete sentences, include lots of ambiguous words, like 'format' which are hard to parse, and include names from the users code which may, or may not make sense in the context of the message. Start to clean this up and provide some guidance for fixes. Also, add a test for one of the messages which didn't have a test at all. Differential Revision: https://reviews.llvm.org/D77449
2020-04-04 09:17:51 +08:00
// CHECK: note: suggest adding a '$successor' directive to the custom assembly format
def ZCoverageInvalidF : TestFormat_Op<"variable_invalid_f", [{
attr-dict
}]> {
let successors = (successor AnySuccessor:$successor);
}
[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: error: type of operand #0, named 'operand', is not buildable and a buildable type cannot be inferred
// CHECK: note: suggest adding a type constraint to the operation or adding a 'type($operand)' directive to the custom assembly format
def ZCoverageInvalidG : TestFormat_Op<"variable_invalid_g", [{
operands attr-dict
}]>, Arguments<(ins Optional<I64>:$operand)>;
// CHECK: error: type of result #0, named 'result', is not buildable and a buildable type cannot be inferred
// CHECK: note: suggest adding a type constraint to the operation or adding a 'type($result)' directive to the custom assembly format
def ZCoverageInvalidH : TestFormat_Op<"variable_invalid_h", [{
attr-dict
}]>, Results<(outs Optional<I64>:$result)>;
[mlir] Add initial support for parsing a declarative operation assembly format Summary: This is the first revision in a series that adds support for declaratively specifying the asm format of an operation. This revision focuses solely on parsing the format. Future revisions will add support for generating the proper parser/printer, as well as transitioning the syntax definition of many existing operations. This was originally proposed here: https://llvm.discourse.group/t/rfc-declarative-op-assembly-format/340 Differential Revision: https://reviews.llvm.org/D73405
2020-01-31 03:30:23 +08:00
// CHECK-NOT: error
def ZCoverageValidA : TestFormat_Op<"variable_valid_a", [{
$operand type($operand) type($result) attr-dict
}]>, Arguments<(ins AnyMemRef:$operand)>, Results<(outs AnyMemRef:$result)>;
def ZCoverageValidB : TestFormat_Op<"variable_valid_b", [{
$operand type(operands) type(results) attr-dict
}]>, Arguments<(ins AnyMemRef:$operand)>, Results<(outs AnyMemRef:$result)>;
def ZCoverageValidC : TestFormat_Op<"variable_valid_c", [{
operands functional-type(operands, results) attr-dict
}]>, Arguments<(ins AnyMemRef:$operand)>, Results<(outs AnyMemRef:$result)>;
[mlir] Initial support for type constraints in the declarative assembly format Summary: This revision add support for accepting a few type constraints, e.g. AllTypesMatch, when inferring types for operands and results. This is used to remove the c++ parsers for several additional operations. Differential Revision: https://reviews.llvm.org/D73735
2020-02-04 13:52:38 +08:00
// Check that we can infer type equalities from certain traits.
def ZCoverageValidD : TestFormat_Op<"variable_valid_d", [{
operands type($result) attr-dict
}], [SameOperandsAndResultType]>, Arguments<(ins AnyMemRef:$operand)>,
Results<(outs AnyMemRef:$result)>;
def ZCoverageValidE : TestFormat_Op<"variable_valid_e", [{
$operand type($operand) attr-dict
}], [SameOperandsAndResultType]>, Arguments<(ins AnyMemRef:$operand)>,
Results<(outs AnyMemRef:$result)>;
def ZCoverageValidF : TestFormat_Op<"variable_valid_f", [{
operands type($other) attr-dict
}], [SameTypeOperands]>, Arguments<(ins AnyMemRef:$operand, AnyMemRef:$other)>;
def ZCoverageValidG : TestFormat_Op<"variable_valid_g", [{
operands type($other) attr-dict
}], [AllTypesMatch<["operand", "other"]>]>,
Arguments<(ins AnyMemRef:$operand, AnyMemRef:$other)>;
def ZCoverageValidH : TestFormat_Op<"variable_valid_h", [{
operands type($result) attr-dict
}], [AllTypesMatch<["operand", "result"]>]>,
Arguments<(ins AnyMemRef:$operand)>, Results<(outs AnyMemRef:$result)>;