maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/mlir/test/IR/parser.mlir

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

1260 lines
51 KiB
MLIR
Raw Normal View History

Add a flag on the context to protect against creation of operations in unregistered dialects Differential Revision: https://reviews.llvm.org/D76903
2020-03-30 06:35:38 +08:00
// RUN: mlir-opt -allow-unregistered-dialect %s | FileCheck %s
Implement enough of a lexer and parser for MLIR to parse extfunc's without arguments. PiperOrigin-RevId: 201706570
2018-06-23 01:39:19 +08:00
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
// CHECK-DAG: #map{{[0-9]+}} = affine_map<(d0, d1, d2, d3, d4)[s0] -> (d0, d1, d2, d4, d3)>
#map0 = affine_map<(d0, d1, d2, d3, d4)[s0] -> (d0, d1, d2, d4, d3)>
Adds ModuleState to support printing outlined AffineMaps. PiperOrigin-RevId: 204999887
2018-07-18 07:56:54 +08:00
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
// CHECK-DAG: #map{{[0-9]+}} = affine_map<(d0) -> (d0)>
#map1 = affine_map<(d0) -> (d0)>
Adds ModuleState to support printing outlined AffineMaps. PiperOrigin-RevId: 204999887
2018-07-18 07:56:54 +08:00
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
// CHECK-DAG: #map{{[0-9]+}} = affine_map<(d0, d1, d2) -> (d0, d1, d2)>
#map2 = affine_map<(d0, d1, d2) -> (d0, d1, d2)>
Adds ModuleState to support printing outlined AffineMaps. PiperOrigin-RevId: 204999887
2018-07-18 07:56:54 +08:00
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
// CHECK-DAG: #map{{[0-9]+}} = affine_map<(d0, d1, d2) -> (d1, d0, d2)>
#map3 = affine_map<(d0, d1, d2) -> (d1, d0, d2)>
Adds ModuleState to support printing outlined AffineMaps. PiperOrigin-RevId: 204999887
2018-07-18 07:56:54 +08:00
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
// CHECK-DAG: #map{{[0-9]+}} = affine_map<(d0, d1, d2) -> (d2, d1, d0)>
#map4 = affine_map<(d0, d1, d2) -> (d2, d1, d0)>
Implement enough of a lexer and parser for MLIR to parse extfunc's without arguments. PiperOrigin-RevId: 201706570
2018-06-23 01:39:19 +08:00
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
// CHECK-DAG: #map{{[0-9]+}} = affine_map<()[s0] -> (0, s0 - 1)>
#inline_map_minmax_loop1 = affine_map<()[s0] -> (0, s0 - 1)>
Implement operands for the lower and upper bounds of the for statement. This revamps implementation of the loop bounds in the ForStmt, using general representation that supports operands. The frequent case of constant bounds is supported via special access methods. This also includes: - Operand iterators for the Statement class. - OpPointer::is() method to query the class of the Operation. - Support for the bound shorthand notation parsing and printing. - Validity checks for the bound operands used as dim ids and symbols I didn't mean this CL to be so large. It just happened this way, as one thing led to another. PiperOrigin-RevId: 210204858
2018-08-25 14:38:14 +08:00
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
// CHECK-DAG: #map{{[0-9]+}} = affine_map<()[s0] -> (100, s0 + 1)>
#inline_map_minmax_loop2 = affine_map<()[s0] -> (100, s0 + 1)>
Implement operands for the lower and upper bounds of the for statement. This revamps implementation of the loop bounds in the ForStmt, using general representation that supports operands. The frequent case of constant bounds is supported via special access methods. This also includes: - Operand iterators for the Statement class. - OpPointer::is() method to query the class of the Operation. - Support for the bound shorthand notation parsing and printing. - Validity checks for the bound operands used as dim ids and symbols I didn't mean this CL to be so large. It just happened this way, as one thing led to another. PiperOrigin-RevId: 210204858
2018-08-25 14:38:14 +08:00
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
// CHECK-DAG: #map{{[0-9]+}} = affine_map<(d0, d1)[s0] -> (d0 + d1 + s0)>
#bound_map1 = affine_map<(i, j)[s] -> (i + j + s)>
Implement operands for the lower and upper bounds of the for statement. This revamps implementation of the loop bounds in the ForStmt, using general representation that supports operands. The frequent case of constant bounds is supported via special access methods. This also includes: - Operand iterators for the Statement class. - OpPointer::is() method to query the class of the Operation. - Support for the bound shorthand notation parsing and printing. - Validity checks for the bound operands used as dim ids and symbols I didn't mean this CL to be so large. It just happened this way, as one thing led to another. PiperOrigin-RevId: 210204858
2018-08-25 14:38:14 +08:00
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
// CHECK-DAG: #map{{[0-9]+}} = affine_map<(d0, d1) -> (d0 + d1)>
#inline_map_loop_bounds2 = affine_map<(d0, d1) -> (d0 + d1)>
Implement operands for the lower and upper bounds of the for statement. This revamps implementation of the loop bounds in the ForStmt, using general representation that supports operands. The frequent case of constant bounds is supported via special access methods. This also includes: - Operand iterators for the Statement class. - OpPointer::is() method to query the class of the Operation. - Support for the bound shorthand notation parsing and printing. - Validity checks for the bound operands used as dim ids and symbols I didn't mean this CL to be so large. It just happened this way, as one thing led to another. PiperOrigin-RevId: 210204858
2018-08-25 14:38:14 +08:00
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
// CHECK-DAG: #map{{[0-9]+}} = affine_map<(d0)[s0] -> (d0 + s0, d0 - s0)>
#bound_map2 = affine_map<(i)[s] -> (i + s, i - s)>
Implement operands for the lower and upper bounds of the for statement. This revamps implementation of the loop bounds in the ForStmt, using general representation that supports operands. The frequent case of constant bounds is supported via special access methods. This also includes: - Operand iterators for the Statement class. - OpPointer::is() method to query the class of the Operation. - Support for the bound shorthand notation parsing and printing. - Validity checks for the bound operands used as dim ids and symbols I didn't mean this CL to be so large. It just happened this way, as one thing led to another. PiperOrigin-RevId: 210204858
2018-08-25 14:38:14 +08:00
Drop unbounded identity map from MemRef affine map composition. Unbounded identity maps do not affect the accesses through MemRefs in any way. A previous CL dropped such maps only if they were alone in the composition. Go further and drop such maps everywhere they appear in the composition. Update the parser test to check for unique'd hoisted map to be present but without assuming any particular order. Because some of the hoisted identity maps still apear due to the nested "for" statements, we need to check for them. However, they no longer appear above the non-identity maps because they are no longer necessary for the extfunc memref declarations that are textually first in the test file. This order may change further as map simplification is improved, there is no reason to assume a particular order. PiperOrigin-RevId: 219287280
2018-10-30 21:11:29 +08:00
// All maps appear in arbitrary order before all sets, in arbitrary order.
Fix CHECK-EMPTY directives without trailing colon There are no empty lines in output for three of these directives so removed them and replaced the remaining one with 'CHECK-NOT:' as otherwise it is failing with the following error. error: found 'CHECK-EMPTY' without previous 'CHECK: line TESTED = n/a PiperOrigin-RevId: 243288605
2019-04-13 01:31:21 +08:00
// CHECK-NOT: Placeholder
Drop unbounded identity map from MemRef affine map composition. Unbounded identity maps do not affect the accesses through MemRefs in any way. A previous CL dropped such maps only if they were alone in the composition. Go further and drop such maps everywhere they appear in the composition. Update the parser test to check for unique'd hoisted map to be present but without assuming any particular order. Because some of the hoisted identity maps still apear due to the nested "for" statements, we need to check for them. However, they no longer appear above the non-identity maps because they are no longer necessary for the extfunc memref declarations that are textually first in the test file. This order may change further as map simplification is improved, there is no reason to assume a particular order. PiperOrigin-RevId: 219287280
2018-10-30 21:11:29 +08:00
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
// CHECK-DAG: #set{{[0-9]+}} = affine_set<(d0)[s0, s1] : (d0 >= 0, -d0 + s0 >= 0, s0 - 5 == 0, -d0 + s1 + 1 >= 0)>
#set0 = affine_set<(i)[N, M] : (i >= 0, -i + N >= 0, N - 5 == 0, -i + M + 1 >= 0)>
Support for affine integer sets - introduce affine integer sets into the IR - parse and print affine integer sets (both inline or outlined) similar to affine maps - use integer set for IfStmt's conditional, and implement parsing of IfStmt's conditional - fixed an affine expr paren omission bug while one this. TODO: parse/represent/print MLValue operands to affine integer set references. PiperOrigin-RevId: 207779408
2018-08-08 05:24:38 +08:00
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
// CHECK-DAG: #set{{[0-9]+}} = affine_set<(d0, d1)[s0] : (d0 >= 0, d1 >= 0)>
#set1 = affine_set<(d0, d1)[s0] : (d0 >= 0, d1 >= 0)>
Introduce integer set attribute - add IntegerSetAttr to Attributes; add parsing and other support for it (builder, etc.). PiperOrigin-RevId: 218804579
2018-10-26 13:13:03 +08:00
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
// CHECK-DAG: #set{{[0-9]+}} = affine_set<(d0) : (d0 - 1 == 0)>
#set2 = affine_set<(d0) : (d0 - 1 == 0)>
Introduce integer set attribute - add IntegerSetAttr to Attributes; add parsing and other support for it (builder, etc.). PiperOrigin-RevId: 218804579
2018-10-26 13:13:03 +08:00
Enable FileCheck -enable-var-scope by default in MLIR test This option avoids to accidentally reuse variable across -LABEL match, it can be explicitly opted-in by prefixing the variable name with $ Differential Revision: https://reviews.llvm.org/D81531
2020-06-12 08:34:35 +08:00
// CHECK-DAG: [[$SET_TRUE:#set[0-9]+]] = affine_set<() : (0 == 0)>
When parsing, treat an IntegerSet with no constraints as a degenerate true case. Also update the spec to note that affine constraints are optional. PiperOrigin-RevId: 232158673
2019-02-03 13:01:11 +08:00
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
// CHECK-DAG: #set{{[0-9]+}} = affine_set<(d0)[s0] : (d0 - 2 >= 0, -d0 + 4 >= 0)>
Support for affine integer sets - introduce affine integer sets into the IR - parse and print affine integer sets (both inline or outlined) similar to affine maps - use integer set for IfStmt's conditional, and implement parsing of IfStmt's conditional - fixed an affine expr paren omission bug while one this. TODO: parse/represent/print MLValue operands to affine integer set references. PiperOrigin-RevId: 207779408
2018-08-08 05:24:38 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @foo(i32, i64) -> f32
func @foo(i32, i64) -> f32
Implement enough of a lexer and parser for MLIR to parse extfunc's without arguments. PiperOrigin-RevId: 201706570
2018-06-23 01:39:19 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @bar()
func @bar() -> ()
Implement enough of a lexer and parser for MLIR to parse extfunc's without arguments. PiperOrigin-RevId: 201706570
2018-06-23 01:39:19 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @baz() -> (i1, index, f32)
func @baz() -> (i1, index, f32)
Implement enough of a lexer and parser for MLIR to parse extfunc's without arguments. PiperOrigin-RevId: 201706570
2018-06-23 01:39:19 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @missingReturn()
func @missingReturn()
Implement parser and lexer support for most of the type grammar. Semi-affine maps and address spaces are not yet supported (someone want to take this on?). We also don't generate IR objects for types yet, which I plan to tackle next. PiperOrigin-RevId: 201754283
2018-06-23 06:52:02 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @int_types(i1, i2, i4, i7, i87) -> (i1, index, i19)
func @int_types(i1, i2, i4, i7, i87) -> (i1, index, i19)
Enhance the type system to support arbitrary precision integers, which are important for low-bitwidth inference cases and hardware synthesis targets. Rename 'int' to 'affineint' to avoid confusion between "the integers" and "the int type". PiperOrigin-RevId: 202751508
2018-06-30 13:08:05 +08:00
[mlir] Add a signedness semantics bit to IntegerType Thus far IntegerType has been signless: a value of IntegerType does not have a sign intrinsically and it's up to the specific operation to decide how to interpret those bits. For example, std.addi does two's complement arithmetic, and std.divis/std.diviu treats the first bit as a sign. This design choice was made some time ago when we did't have lots of dialects and dialects were more rigid. Today we have much more extensible infrastructure and different dialect may want different modelling over integer signedness. So while we can say we want signless integers in the standard dialect, we cannot dictate for others. Requiring each dialect to model the signedness semantics with another set of custom types is duplicating the functionality everywhere, considering the fundamental role integer types play. This CL extends the IntegerType with a signedness semantics bit. This gives each dialect an option to opt in signedness semantics if that's what they want and helps code sharing. The parser is modified to recognize `si[1-9][0-9]*` and `ui[1-9][0-9]*` as signed and unsigned integer types, respectively, leaving the original `i[1-9][0-9]*` to continue to mean no indication over signedness semantics. All existing dialects are not affected (yet) as this is a feature to opt in. More discussions can be found at: https://groups.google.com/a/tensorflow.org/d/msg/mlir/XmkV8HOPWpo/7O4X0Nb_AQAJ Differential Revision: https://reviews.llvm.org/D72533
2020-01-11 03:48:24 +08:00
// CHECK: func @sint_types(si2, si4) -> (si7, si1023)
func @sint_types(si2, si4) -> (si7, si1023)
// CHECK: func @uint_types(ui2, ui4) -> (ui7, ui1023)
func @uint_types(ui2, ui4) -> (ui7, ui1023)
Implement parser and lexer support for most of the type grammar. Semi-affine maps and address spaces are not yet supported (someone want to take this on?). We also don't generate IR objects for types yet, which I plan to tackle next. PiperOrigin-RevId: 201754283
2018-06-23 06:52:02 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @vectors(vector<1xf32>, vector<2x4xf32>)
func @vectors(vector<1 x f32>, vector<2x4xf32>)
Implement parser and lexer support for most of the type grammar. Semi-affine maps and address spaces are not yet supported (someone want to take this on?). We also don't generate IR objects for types yet, which I plan to tackle next. PiperOrigin-RevId: 201754283
2018-06-23 06:52:02 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @tensors(tensor<*xf32>, tensor<*xvector<2x4xf32>>, tensor<1x?x4x?x?xi32>, tensor<i8>)
func @tensors(tensor<* x f32>, tensor<* x vector<2x4xf32>>,
Eliminate "primitive" types from being a thing, splitting them into FloatType and OtherType. Other type is now the thing that holds AffineInt, Control, eventually Resource, Variant, String, etc. FloatType holds the floating point types, and allows convenient query of isa<FloatType>(). This fixes issues where we allowed control to be the element type of tensor, memref, vector. At the same time, ban AffineInt from being an element of a vector/memref/tensor as well since we don't need it. I updated the spec to match this as well. PiperOrigin-RevId: 206361942
2018-07-28 04:09:58 +08:00
tensor<1x?x4x?x?xi32>, tensor<i8>)
Implement parser and lexer support for most of the type grammar. Semi-affine maps and address spaces are not yet supported (someone want to take this on?). We also don't generate IR objects for types yet, which I plan to tackle next. PiperOrigin-RevId: 201754283
2018-06-23 06:52:02 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @memrefs(memref<1x?x4x?x?xi32, #map{{[0-9]+}}>, memref<8xi8>)
func @memrefs(memref<1x?x4x?x?xi32, #map0>, memref<8xi8, #map1, #map1>)
Introduce IR support for MLIRContext, primitive types, function types, and vector types. tensors and memref types are still TODO, and would be a good starter project for someone. PiperOrigin-RevId: 201782748
2018-06-23 13:03:48 +08:00
Adds MemRef type and adds support for parsing memref affine map composition. PiperOrigin-RevId: 204756982
2018-07-17 00:45:22 +08:00
// Test memref affine map compositions.
Implement parser/IR support for CFG functions, basic blocks and return instruction. This is pretty much minimal scaffolding for this step. Basic block arguments, instructions, other terminators, a proper IR representation for blocks/instructions, etc are all coming. PiperOrigin-RevId: 201826439
2018-06-24 07:03:42 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @memrefs2(memref<2x4x8xi8, 1>)
func @memrefs2(memref<2x4x8xi8, #map2, 1>)
Adds MemRef type and adds support for parsing memref affine map composition. PiperOrigin-RevId: 204756982
2018-07-17 00:45:22 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @memrefs23(memref<2x4x8xi8, #map{{[0-9]+}}>)
func @memrefs23(memref<2x4x8xi8, #map2, #map3, 0>)
Adds MemRef type and adds support for parsing memref affine map composition. PiperOrigin-RevId: 204756982
2018-07-17 00:45:22 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @memrefs234(memref<2x4x8xi8, #map{{[0-9]+}}, #map{{[0-9]+}}, 3>)
func @memrefs234(memref<2x4x8xi8, #map2, #map3, #map4, 3>)
Adds MemRef type and adds support for parsing memref affine map composition. PiperOrigin-RevId: 204756982
2018-07-17 00:45:22 +08:00
Drop unbounded identity map from MemRef affine map composition. Unbounded identity maps do not affect the accesses through MemRefs in any way. A previous CL dropped such maps only if they were alone in the composition. Go further and drop such maps everywhere they appear in the composition. Update the parser test to check for unique'd hoisted map to be present but without assuming any particular order. Because some of the hoisted identity maps still apear due to the nested "for" statements, we need to check for them. However, they no longer appear above the non-identity maps because they are no longer necessary for the extfunc memref declarations that are textually first in the test file. This order may change further as map simplification is improved, there is no reason to assume a particular order. PiperOrigin-RevId: 219287280
2018-10-30 21:11:29 +08:00
// Test memref inline affine map compositions, minding that identity maps are removed.
Adds MemRef type and adds support for parsing memref affine map composition. PiperOrigin-RevId: 204756982
2018-07-17 00:45:22 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @memrefs3(memref<2x4x8xi8>)
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
func @memrefs3(memref<2x4x8xi8, affine_map<(d0, d1, d2) -> (d0, d1, d2)>>)
Adds MemRef type and adds support for parsing memref affine map composition. PiperOrigin-RevId: 204756982
2018-07-17 00:45:22 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @memrefs33(memref<2x4x8xi8, #map{{[0-9]+}}, 1>)
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
func @memrefs33(memref<2x4x8xi8, affine_map<(d0, d1, d2) -> (d0, d1, d2)>, affine_map<(d0, d1, d2) -> (d1, d0, d2)>, 1>)
Adds MemRef type and adds support for parsing memref affine map composition. PiperOrigin-RevId: 204756982
2018-07-17 00:45:22 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @memrefs_drop_triv_id_inline(memref<2xi8>)
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
func @memrefs_drop_triv_id_inline(memref<2xi8, affine_map<(d0) -> (d0)>>)
Drop trivial identity affine mappings in MemRef construction. As per MLIR spec, the absence of affine maps in MemRef type is interpreted as an implicit identity affine map. Therefore, MemRef types declared with explicit or implicit identity map should be considered equal at the MemRefType level. During MemRefType construction, drop trivial identity affine map compositions. A trivial identity composition consists of a single unbounded identity map. It is unclear whether affine maps should be composed in-place to a single map during MemRef type construction, so non-trivial compositions that could have been simplified to an identity are NOT removed. We chose to drop the trivial identity map rather than inject it in places that assume its present implicitly because it makes the code simpler by reducing boilerplate; identity mappings are obvious defaults. Update tests that were checking for the presence of trivial identity map compositions in the outputs. PiperOrigin-RevId: 218862454
2018-10-27 00:07:10 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @memrefs_drop_triv_id_inline0(memref<2xi8>)
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
func @memrefs_drop_triv_id_inline0(memref<2xi8, affine_map<(d0) -> (d0)>, 0>)
Drop trivial identity affine mappings in MemRef construction. As per MLIR spec, the absence of affine maps in MemRef type is interpreted as an implicit identity affine map. Therefore, MemRef types declared with explicit or implicit identity map should be considered equal at the MemRefType level. During MemRefType construction, drop trivial identity affine map compositions. A trivial identity composition consists of a single unbounded identity map. It is unclear whether affine maps should be composed in-place to a single map during MemRef type construction, so non-trivial compositions that could have been simplified to an identity are NOT removed. We chose to drop the trivial identity map rather than inject it in places that assume its present implicitly because it makes the code simpler by reducing boilerplate; identity mappings are obvious defaults. Update tests that were checking for the presence of trivial identity map compositions in the outputs. PiperOrigin-RevId: 218862454
2018-10-27 00:07:10 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @memrefs_drop_triv_id_inline1(memref<2xi8, 1>)
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
func @memrefs_drop_triv_id_inline1(memref<2xi8, affine_map<(d0) -> (d0)>, 1>)
Drop trivial identity affine mappings in MemRef construction. As per MLIR spec, the absence of affine maps in MemRef type is interpreted as an implicit identity affine map. Therefore, MemRef types declared with explicit or implicit identity map should be considered equal at the MemRefType level. During MemRefType construction, drop trivial identity affine map compositions. A trivial identity composition consists of a single unbounded identity map. It is unclear whether affine maps should be composed in-place to a single map during MemRef type construction, so non-trivial compositions that could have been simplified to an identity are NOT removed. We chose to drop the trivial identity map rather than inject it in places that assume its present implicitly because it makes the code simpler by reducing boilerplate; identity mappings are obvious defaults. Update tests that were checking for the presence of trivial identity map compositions in the outputs. PiperOrigin-RevId: 218862454
2018-10-27 00:07:10 +08:00
Drop unbounded identity map from MemRef affine map composition. Unbounded identity maps do not affect the accesses through MemRefs in any way. A previous CL dropped such maps only if they were alone in the composition. Go further and drop such maps everywhere they appear in the composition. Update the parser test to check for unique'd hoisted map to be present but without assuming any particular order. Because some of the hoisted identity maps still apear due to the nested "for" statements, we need to check for them. However, they no longer appear above the non-identity maps because they are no longer necessary for the extfunc memref declarations that are textually first in the test file. This order may change further as map simplification is improved, there is no reason to assume a particular order. PiperOrigin-RevId: 219287280
2018-10-30 21:11:29 +08:00
// Identity maps should be dropped from the composition, but not the pair of
// "interchange" maps that, if composed, would be also an identity.
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @memrefs_drop_triv_id_composition(memref<2x2xi8, #map{{[0-9]+}}, #map{{[0-9]+}}>)
func @memrefs_drop_triv_id_composition(memref<2x2xi8,
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
affine_map<(d0, d1) -> (d1, d0)>,
affine_map<(d0, d1) -> (d0, d1)>,
affine_map<(d0, d1) -> (d1, d0)>,
affine_map<(d0, d1) -> (d0, d1)>,
affine_map<(d0, d1) -> (d0, d1)>>)
Drop unbounded identity map from MemRef affine map composition. Unbounded identity maps do not affect the accesses through MemRefs in any way. A previous CL dropped such maps only if they were alone in the composition. Go further and drop such maps everywhere they appear in the composition. Update the parser test to check for unique'd hoisted map to be present but without assuming any particular order. Because some of the hoisted identity maps still apear due to the nested "for" statements, we need to check for them. However, they no longer appear above the non-identity maps because they are no longer necessary for the extfunc memref declarations that are textually first in the test file. This order may change further as map simplification is improved, there is no reason to assume a particular order. PiperOrigin-RevId: 219287280
2018-10-30 21:11:29 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @memrefs_drop_triv_id_trailing(memref<2x2xi8, #map{{[0-9]+}}>)
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
func @memrefs_drop_triv_id_trailing(memref<2x2xi8, affine_map<(d0, d1) -> (d1, d0)>,
affine_map<(d0, d1) -> (d0, d1)>>)
Drop unbounded identity map from MemRef affine map composition. Unbounded identity maps do not affect the accesses through MemRefs in any way. A previous CL dropped such maps only if they were alone in the composition. Go further and drop such maps everywhere they appear in the composition. Update the parser test to check for unique'd hoisted map to be present but without assuming any particular order. Because some of the hoisted identity maps still apear due to the nested "for" statements, we need to check for them. However, they no longer appear above the non-identity maps because they are no longer necessary for the extfunc memref declarations that are textually first in the test file. This order may change further as map simplification is improved, there is no reason to assume a particular order. PiperOrigin-RevId: 219287280
2018-10-30 21:11:29 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @memrefs_drop_triv_id_middle(memref<2x2xi8, #map{{[0-9]+}}, #map{{[0-9]+}}>)
Allow '_' when pretty printing dialect symbols '_' is used frequently enough as the separator of words in symbols. We should allow it in dialect symbols when considering pretty printing. Also updated LangRef.md regarding pretty form. PiperOrigin-RevId: 275312494
2019-10-18 03:23:47 +08:00
func @memrefs_drop_triv_id_middle(memref<2x2xi8,
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
affine_map<(d0, d1) -> (d0, d1 + 1)>,
affine_map<(d0, d1) -> (d0, d1)>,
affine_map<(d0, d1) -> (d0 + 1, d1)>>)
Drop unbounded identity map from MemRef affine map composition. Unbounded identity maps do not affect the accesses through MemRefs in any way. A previous CL dropped such maps only if they were alone in the composition. Go further and drop such maps everywhere they appear in the composition. Update the parser test to check for unique'd hoisted map to be present but without assuming any particular order. Because some of the hoisted identity maps still apear due to the nested "for" statements, we need to check for them. However, they no longer appear above the non-identity maps because they are no longer necessary for the extfunc memref declarations that are textually first in the test file. This order may change further as map simplification is improved, there is no reason to assume a particular order. PiperOrigin-RevId: 219287280
2018-10-30 21:11:29 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @memrefs_drop_triv_id_multiple(memref<2xi8>)
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
func @memrefs_drop_triv_id_multiple(memref<2xi8, affine_map<(d0) -> (d0)>, affine_map<(d0) -> (d0)>>)
Drop unbounded identity map from MemRef affine map composition. Unbounded identity maps do not affect the accesses through MemRefs in any way. A previous CL dropped such maps only if they were alone in the composition. Go further and drop such maps everywhere they appear in the composition. Update the parser test to check for unique'd hoisted map to be present but without assuming any particular order. Because some of the hoisted identity maps still apear due to the nested "for" statements, we need to check for them. However, they no longer appear above the non-identity maps because they are no longer necessary for the extfunc memref declarations that are textually first in the test file. This order may change further as map simplification is improved, there is no reason to assume a particular order. PiperOrigin-RevId: 219287280
2018-10-30 21:11:29 +08:00
Drop trivial identity affine mappings in MemRef construction. As per MLIR spec, the absence of affine maps in MemRef type is interpreted as an implicit identity affine map. Therefore, MemRef types declared with explicit or implicit identity map should be considered equal at the MemRefType level. During MemRefType construction, drop trivial identity affine map compositions. A trivial identity composition consists of a single unbounded identity map. It is unclear whether affine maps should be composed in-place to a single map during MemRef type construction, so non-trivial compositions that could have been simplified to an identity are NOT removed. We chose to drop the trivial identity map rather than inject it in places that assume its present implicitly because it makes the code simpler by reducing boilerplate; identity mappings are obvious defaults. Update tests that were checking for the presence of trivial identity map compositions in the outputs. PiperOrigin-RevId: 218862454
2018-10-27 00:07:10 +08:00
// These maps appeared before, so they must be uniqued and hoisted to the beginning.
Drop unbounded identity map from MemRef affine map composition. Unbounded identity maps do not affect the accesses through MemRefs in any way. A previous CL dropped such maps only if they were alone in the composition. Go further and drop such maps everywhere they appear in the composition. Update the parser test to check for unique'd hoisted map to be present but without assuming any particular order. Because some of the hoisted identity maps still apear due to the nested "for" statements, we need to check for them. However, they no longer appear above the non-identity maps because they are no longer necessary for the extfunc memref declarations that are textually first in the test file. This order may change further as map simplification is improved, there is no reason to assume a particular order. PiperOrigin-RevId: 219287280
2018-10-30 21:11:29 +08:00
// Identity map should be removed.
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @memrefs_compose_with_id(memref<2x2xi8, #map{{[0-9]+}}>)
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
func @memrefs_compose_with_id(memref<2x2xi8, affine_map<(d0, d1) -> (d0, d1)>,
affine_map<(d0, d1) -> (d1, d0)>>)
Drop trivial identity affine mappings in MemRef construction. As per MLIR spec, the absence of affine maps in MemRef type is interpreted as an implicit identity affine map. Therefore, MemRef types declared with explicit or implicit identity map should be considered equal at the MemRefType level. During MemRefType construction, drop trivial identity affine map compositions. A trivial identity composition consists of a single unbounded identity map. It is unclear whether affine maps should be composed in-place to a single map during MemRef type construction, so non-trivial compositions that could have been simplified to an identity are NOT removed. We chose to drop the trivial identity map rather than inject it in places that assume its present implicitly because it makes the code simpler by reducing boilerplate; identity mappings are obvious defaults. Update tests that were checking for the presence of trivial identity map compositions in the outputs. PiperOrigin-RevId: 218862454
2018-10-27 00:07:10 +08:00
Implement basic IR support for a builtin complex<> type. As with tuples, we have no standard ops for working with these yet, this is simply enough to represent and round trip them in the printer and parser. -- PiperOrigin-RevId: 241102728
2019-03-30 13:23:34 +08:00
// CHECK: func @complex_types(complex<i1>) -> complex<f32>
func @complex_types(complex<i1>) -> complex<f32>
[MLIR] Support memrefs with complex element types. Differential Revision: https://reviews.llvm.org/D74307
2020-02-12 16:04:15 +08:00
// CHECK: func @memref_with_complex_elems(memref<1x?xcomplex<f32>>)
func @memref_with_complex_elems(memref<1x?xcomplex<f32>>)
// CHECK: func @memref_with_vector_elems(memref<1x?xvector<10xf32>>)
func @memref_with_vector_elems(memref<1x?xvector<10xf32>>)
// CHECK: func @unranked_memref_with_complex_elems(memref<*xcomplex<f32>>)
func @unranked_memref_with_complex_elems(memref<*xcomplex<f32>>)
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK: func @functions((memref<1x?x4x?x?xi32, #map0>, memref<8xi8>) -> (), () -> ())
func @functions((memref<1x?x4x?x?xi32, #map0, 0>, memref<8xi8, #map1, 0>) -> (), ()->())
Implement parser/IR support for CFG functions, basic blocks and return instruction. This is pretty much minimal scaffolding for this step. Basic block arguments, instructions, other terminators, a proper IR representation for blocks/instructions, etc are all coming. PiperOrigin-RevId: 201826439
2018-06-24 07:03:42 +08:00
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK-LABEL: func @simpleCFG(%{{.*}}: i32, %{{.*}}: f32) -> i1 {
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
func @simpleCFG(%arg0: i32, %f: f32) -> i1 {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = "foo"() : () -> i64
Add basic parser support for operands: - This introduces a new FunctionParser base class to handle logic common between the kinds of functions we have, e.g. ssa operand/def parsing. - This introduces a basic symbol table (without support for forward references!) and links defs and uses. - CFG functions now parse and build operand lists for operations. The printer isn't set up for them yet tho. PiperOrigin-RevId: 205246110
2018-07-19 23:35:28 +08:00
%1 = "foo"() : ()->i64
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: "bar"(%{{.*}}) : (i64) -> (i1, i1, i1)
Change the muli-return syntax for operations. The name of the operation result now contains the number of results that it refers to if the number of results is greater than 1. Example: %call:2 = call @multi_return() : () -> (f32, i32) use(%calltensorflow/mlir#0, %calltensorflow/mlir#1) This cl also adds parser support for uniquely named result values. This means that a test writer can now write something like: %foo, %bar = call @multi_return() : () -> (f32, i32) use(%foo, %bar) Note: The printer will still print the collapsed form. PiperOrigin-RevId: 240860058
2019-03-29 05:58:52 +08:00
%2:3 = "bar"(%1) : (i64) -> (i1,i1,i1)
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: return %{{.*}}#1
Implement support for branch instruction operands. PiperOrigin-RevId: 205666777
2018-07-23 23:42:19 +08:00
return %2#1 : i1
Initial support for operands and results and SSA constructs, first on the instruction side of the house. This has a number of limitations, including that we are still dropping operands on the floor in the parser. Also, most of the convenience methods aren't wired up yet. This is enough to get result type lists round tripping through. PiperOrigin-RevId: 205148223
2018-07-19 06:31:25 +08:00
// CHECK: }
}
Implement parser/IR support for CFG functions, basic blocks and return instruction. This is pretty much minimal scaffolding for this step. Basic block arguments, instructions, other terminators, a proper IR representation for blocks/instructions, etc are all coming. PiperOrigin-RevId: 201826439
2018-06-24 07:03:42 +08:00
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK-LABEL: func @simpleCFGUsingBBArgs(%{{.*}}: i32, %{{.*}}: i64) {
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
func @simpleCFGUsingBBArgs(i32, i64) {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb42 (%arg0: i32, %f: i64):
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: "bar"(%{{.*}}) : (i64) -> (i1, i1, i1)
Change the muli-return syntax for operations. The name of the operation result now contains the number of results that it refers to if the number of results is greater than 1. Example: %call:2 = call @multi_return() : () -> (f32, i32) use(%calltensorflow/mlir#0, %calltensorflow/mlir#1) This cl also adds parser support for uniquely named result values. This means that a test writer can now write something like: %foo, %bar = call @multi_return() : () -> (f32, i32) use(%foo, %bar) Note: The printer will still print the collapsed form. PiperOrigin-RevId: 240860058
2019-03-29 05:58:52 +08:00
%2:3 = "bar"(%f) : (i64) -> (i1,i1,i1)
[mlir] Fix ReturnInst printing for zero operands No longer prints a trailing ':'. PiperOrigin-RevId: 207103812
2018-08-02 23:28:20 +08:00
// CHECK: return{{$}}
[mlir] Add basic block arguments This patch adds support for basic block arguments including parsing and printing. In doing so noticed that `ssa-id-and-type` is undefined in the MLIR spec; suggested an implementation in the spec doc. PiperOrigin-RevId: 205593369
2018-07-23 06:45:24 +08:00
return
// CHECK: }
}
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @multiblock() {
func @multiblock() {
Switch the comment syntax from ; to // comments as discussed on Friday. There is no strong reason to prefer one or the other, but // is nice for consistency given the rest of the compiler is written in C++. PiperOrigin-RevId: 204628476
2018-07-15 14:06:24 +08:00
return // CHECK: return
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb1: // CHECK: ^bb1: // no predecessors
br ^bb4 // CHECK: br ^bb3
^bb2: // CHECK: ^bb2: // pred: ^bb2
br ^bb2 // CHECK: br ^bb2
^bb4: // CHECK: ^bb3: // pred: ^bb1
Switch the comment syntax from ; to // comments as discussed on Friday. There is no strong reason to prefer one or the other, but // is nice for consistency given the rest of the compiler is written in C++. PiperOrigin-RevId: 204628476
2018-07-15 14:06:24 +08:00
return // CHECK: return
} // CHECK: }
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @emptyMLF() {
func @emptyMLF() {
Switch the comment syntax from ; to // comments as discussed on Friday. There is no strong reason to prefer one or the other, but // is nice for consistency given the rest of the compiler is written in C++. PiperOrigin-RevId: 204628476
2018-07-15 14:06:24 +08:00
return // CHECK: return
} // CHECK: }
Introduce IR and parser support for ML functions. Representing function arguments is still TODO. Supporting instructions other than return is also TODO. PiperOrigin-RevId: 202570934
2018-06-29 08:02:32 +08:00
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK-LABEL: func @func_with_one_arg(%{{.*}}: i1) -> i2 {
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
func @func_with_one_arg(%c : i1) -> i2 {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = "foo"(%{{.*}}) : (i1) -> i2
Implement ML function arguments. Add representation for argument list in ML Function using TrailingObjects template. Implement argument iterators, parsing and printing. Unrelated minor change - remove OperationStmt::dropReferences(). Since MLFunction does not have cyclic operand references (it's an AST) destruction can be safely done w/o a special pass to drop references. PiperOrigin-RevId: 207583024
2018-08-07 02:54:39 +08:00
%b = "foo"(%c) : (i1) -> (i2)
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
return %b : i2 // CHECK: return %{{.*}} : i2
Implement return statement as RetOp operation. Add verification of the return statement placement and operands. Add parser and parsing error tests for return statements with non-zero number of operands. Add a few missing tests for ForStmt parsing errors. Prior to this CL, return statement had no explicit representation in MLIR. Now, it is represented as ReturnOp standard operation and is pretty printed according to the return statement syntax. This way statement walkers can process ML function return operands without making special case for them. PiperOrigin-RevId: 208092424
2018-08-10 03:28:58 +08:00
} // CHECK: }
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK-LABEL: func @func_with_two_args(%{{.*}}: f16, %{{.*}}: i8) -> (i1, i32) {
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
func @func_with_two_args(%a : f16, %b : i8) -> (i1, i32) {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}}:2 = "foo"(%{{.*}}, %{{.*}}) : (f16, i8) -> (i1, i32)
Change the muli-return syntax for operations. The name of the operation result now contains the number of results that it refers to if the number of results is greater than 1. Example: %call:2 = call @multi_return() : () -> (f32, i32) use(%calltensorflow/mlir#0, %calltensorflow/mlir#1) This cl also adds parser support for uniquely named result values. This means that a test writer can now write something like: %foo, %bar = call @multi_return() : () -> (f32, i32) use(%foo, %bar) Note: The printer will still print the collapsed form. PiperOrigin-RevId: 240860058
2019-03-29 05:58:52 +08:00
%c:2 = "foo"(%a, %b) : (f16, i8)->(i1, i32)
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
return %c#0, %c#1 : i1, i32 // CHECK: return %{{.*}}#0, %{{.*}}#1 : i1, i32
Implement return statement as RetOp operation. Add verification of the return statement placement and operands. Add parser and parsing error tests for return statements with non-zero number of operands. Add a few missing tests for ForStmt parsing errors. Prior to this CL, return statement had no explicit representation in MLIR. Now, it is represented as ReturnOp standard operation and is pretty printed according to the return statement syntax. This way statement walkers can process ML function return operands without making special case for them. PiperOrigin-RevId: 208092424
2018-08-10 03:28:58 +08:00
} // CHECK: }
Print parens around the return type of a function if it is also a function type Existing type syntax contains the following productions: function-type ::= type-list-parens `->` type-list type-list ::= type | type-list-parens type ::= <..> | function-type Due to these rules, when the parser sees `->` followed by `(`, it cannot disambiguate if `(` starts a parenthesized list of function result types, or a parenthesized list of operands of another function type, returned from the current function. We would need an unknown amount of lookahead to try to find the `->` at the right level of function nesting to differentiate between type lists and singular function types. Instead, require the result type of the function that is a function type itself to be always parenthesized, at the syntax level. Update the spec and the parser to correspond to the production rule names used in the spec (although it would have worked without modifications). Fix the function type parsing bug in the process, as it used to accept the non-parenthesized list of types for arguments, disallowed by the spec. PiperOrigin-RevId: 232528361
2019-02-06 03:47:02 +08:00
// CHECK-LABEL: func @second_order_func() -> (() -> ()) {
func @second_order_func() -> (() -> ()) {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK-NEXT: %{{.*}} = constant @emptyMLF : () -> ()
Print parens around the return type of a function if it is also a function type Existing type syntax contains the following productions: function-type ::= type-list-parens `->` type-list type-list ::= type | type-list-parens type ::= <..> | function-type Due to these rules, when the parser sees `->` followed by `(`, it cannot disambiguate if `(` starts a parenthesized list of function result types, or a parenthesized list of operands of another function type, returned from the current function. We would need an unknown amount of lookahead to try to find the `->` at the right level of function nesting to differentiate between type lists and singular function types. Instead, require the result type of the function that is a function type itself to be always parenthesized, at the syntax level. Update the spec and the parser to correspond to the production rule names used in the spec (although it would have worked without modifications). Fix the function type parsing bug in the process, as it used to accept the non-parenthesized list of types for arguments, disallowed by the spec. PiperOrigin-RevId: 232528361
2019-02-06 03:47:02 +08:00
%c = constant @emptyMLF : () -> ()
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK-NEXT: return %{{.*}} : () -> ()
Print parens around the return type of a function if it is also a function type Existing type syntax contains the following productions: function-type ::= type-list-parens `->` type-list type-list ::= type | type-list-parens type ::= <..> | function-type Due to these rules, when the parser sees `->` followed by `(`, it cannot disambiguate if `(` starts a parenthesized list of function result types, or a parenthesized list of operands of another function type, returned from the current function. We would need an unknown amount of lookahead to try to find the `->` at the right level of function nesting to differentiate between type lists and singular function types. Instead, require the result type of the function that is a function type itself to be always parenthesized, at the syntax level. Update the spec and the parser to correspond to the production rule names used in the spec (although it would have worked without modifications). Fix the function type parsing bug in the process, as it used to accept the non-parenthesized list of types for arguments, disallowed by the spec. PiperOrigin-RevId: 232528361
2019-02-06 03:47:02 +08:00
return %c : () -> ()
}
// CHECK-LABEL: func @third_order_func() -> (() -> (() -> ())) {
func @third_order_func() -> (() -> (() -> ())) {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK-NEXT: %{{.*}} = constant @second_order_func : () -> (() -> ())
Print parens around the return type of a function if it is also a function type Existing type syntax contains the following productions: function-type ::= type-list-parens `->` type-list type-list ::= type | type-list-parens type ::= <..> | function-type Due to these rules, when the parser sees `->` followed by `(`, it cannot disambiguate if `(` starts a parenthesized list of function result types, or a parenthesized list of operands of another function type, returned from the current function. We would need an unknown amount of lookahead to try to find the `->` at the right level of function nesting to differentiate between type lists and singular function types. Instead, require the result type of the function that is a function type itself to be always parenthesized, at the syntax level. Update the spec and the parser to correspond to the production rule names used in the spec (although it would have worked without modifications). Fix the function type parsing bug in the process, as it used to accept the non-parenthesized list of types for arguments, disallowed by the spec. PiperOrigin-RevId: 232528361
2019-02-06 03:47:02 +08:00
%c = constant @second_order_func : () -> (() -> ())
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK-NEXT: return %{{.*}} : () -> (() -> ())
Print parens around the return type of a function if it is also a function type Existing type syntax contains the following productions: function-type ::= type-list-parens `->` type-list type-list ::= type | type-list-parens type ::= <..> | function-type Due to these rules, when the parser sees `->` followed by `(`, it cannot disambiguate if `(` starts a parenthesized list of function result types, or a parenthesized list of operands of another function type, returned from the current function. We would need an unknown amount of lookahead to try to find the `->` at the right level of function nesting to differentiate between type lists and singular function types. Instead, require the result type of the function that is a function type itself to be always parenthesized, at the syntax level. Update the spec and the parser to correspond to the production rule names used in the spec (although it would have worked without modifications). Fix the function type parsing bug in the process, as it used to accept the non-parenthesized list of types for arguments, disallowed by the spec. PiperOrigin-RevId: 232528361
2019-02-06 03:47:02 +08:00
return %c : () -> (() -> ())
}
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK-LABEL: func @identity_functor(%{{.*}}: () -> ()) -> (() -> ()) {
Print parens around the return type of a function if it is also a function type Existing type syntax contains the following productions: function-type ::= type-list-parens `->` type-list type-list ::= type | type-list-parens type ::= <..> | function-type Due to these rules, when the parser sees `->` followed by `(`, it cannot disambiguate if `(` starts a parenthesized list of function result types, or a parenthesized list of operands of another function type, returned from the current function. We would need an unknown amount of lookahead to try to find the `->` at the right level of function nesting to differentiate between type lists and singular function types. Instead, require the result type of the function that is a function type itself to be always parenthesized, at the syntax level. Update the spec and the parser to correspond to the production rule names used in the spec (although it would have worked without modifications). Fix the function type parsing bug in the process, as it used to accept the non-parenthesized list of types for arguments, disallowed by the spec. PiperOrigin-RevId: 232528361
2019-02-06 03:47:02 +08:00
func @identity_functor(%a : () -> ()) -> (() -> ()) {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK-NEXT: return %{{.*}} : () -> ()
Print parens around the return type of a function if it is also a function type Existing type syntax contains the following productions: function-type ::= type-list-parens `->` type-list type-list ::= type | type-list-parens type ::= <..> | function-type Due to these rules, when the parser sees `->` followed by `(`, it cannot disambiguate if `(` starts a parenthesized list of function result types, or a parenthesized list of operands of another function type, returned from the current function. We would need an unknown amount of lookahead to try to find the `->` at the right level of function nesting to differentiate between type lists and singular function types. Instead, require the result type of the function that is a function type itself to be always parenthesized, at the syntax level. Update the spec and the parser to correspond to the production rule names used in the spec (although it would have worked without modifications). Fix the function type parsing bug in the process, as it used to accept the non-parenthesized list of types for arguments, disallowed by the spec. PiperOrigin-RevId: 232528361
2019-02-06 03:47:02 +08:00
return %a : () -> ()
}
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @func_ops_in_loop() {
func @func_ops_in_loop() {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = "foo"() : () -> i64
Implement MLValue, statement operands, operation statement operands and values. ML functions now have full support for expressing operations. Induction variables, function arguments and return values are still todo. PiperOrigin-RevId: 206253643
2018-07-27 09:09:20 +08:00
%a = "foo"() : ()->i64
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: affine.for %{{.*}} = 1 to 10 {
NFC: Rename the 'for' operation in the AffineOps dialect to 'affine.for' and set the namespace of the AffineOps dialect to 'affine'. PiperOrigin-RevId: 240165792
2019-03-26 01:14:34 +08:00
affine.for %i = 1 to 10 {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = "doo"() : () -> f32
Implement MLValue, statement operands, operation statement operands and values. ML functions now have full support for expressing operations. Induction variables, function arguments and return values are still todo. PiperOrigin-RevId: 206253643
2018-07-27 09:09:20 +08:00
%b = "doo"() : ()->f32
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: "bar"(%{{.*}}, %{{.*}}) : (i64, f32) -> ()
Implement MLValue, statement operands, operation statement operands and values. ML functions now have full support for expressing operations. Induction variables, function arguments and return values are still todo. PiperOrigin-RevId: 206253643
2018-07-27 09:09:20 +08:00
"bar"(%a, %b) : (i64, f32) -> ()
// CHECK: }
}
// CHECK: return
return
// CHECK: }
}
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @loops() {
func @loops() {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: affine.for %{{.*}} = 1 to 100 step 2 {
NFC: Rename the 'for' operation in the AffineOps dialect to 'affine.for' and set the namespace of the AffineOps dialect to 'affine'. PiperOrigin-RevId: 240165792
2019-03-26 01:14:34 +08:00
affine.for %i = 1 to 100 step 2 {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: affine.for %{{.*}} = 1 to 200 {
NFC: Rename the 'for' operation in the AffineOps dialect to 'affine.for' and set the namespace of the AffineOps dialect to 'affine'. PiperOrigin-RevId: 240165792
2019-03-26 01:14:34 +08:00
affine.for %j = 1 to 200 {
Switch the comment syntax from ; to // comments as discussed on Friday. There is no strong reason to prefer one or the other, but // is nice for consistency given the rest of the compiler is written in C++. PiperOrigin-RevId: 204628476
2018-07-15 14:06:24 +08:00
} // CHECK: }
} // CHECK: }
return // CHECK: return
} // CHECK: }
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @complex_loops() {
func @complex_loops() {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
affine.for %i1 = 1 to 100 { // CHECK: affine.for %{{.*}} = 1 to 100 {
affine.for %j1 = 1 to 100 { // CHECK: affine.for %{{.*}} = 1 to 100 {
// CHECK: "foo"(%{{.*}}, %{{.*}}) : (index, index) -> ()
Rename affineint type to index type. The name 'index' may not be perfect, but is better than the old name. Here is some justification: 1) affineint (as it is named) is not a type suitable for general computation (e.g. the multiply/adds in an integer matmul). It has undefined width and is undefined on overflow. They are used as the indices for forstmt because they are intended to be used as indexes inside the loop. 2) It can be used in both cfg and ml functions, and in cfg functions. As you mention, “symbols” are not affine, and we use affineint values for symbols. 3) Integers aren’t affine, the algorithms applied to them can be. :) 4) The only suitable use for affineint in MLIR is for indexes and dimension sizes (i.e. the bounds of those indexes). PiperOrigin-RevId: 216057974
2018-10-07 08:21:53 +08:00
"foo"(%i1, %j1) : (index,index) -> ()
Implement induction variables. Pretty print induction variable operands as %i<ssa value number>. Add support for future pretty printing of ML function arguments as %arg<ssa value number>. Induction variables are implemented by inheriting ForStmt from MLValue. ForStmt provides APIs that make this design decision invisible to the ForStmt users. This CL in combination with cl/206253643 resolves http://b/111769060. PiperOrigin-RevId: 206655937
2018-07-31 06:18:10 +08:00
} // CHECK: }
"boo"() : () -> () // CHECK: "boo"() : () -> ()
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
affine.for %j2 = 1 to 10 { // CHECK: affine.for %{{.*}} = 1 to 10 {
affine.for %k2 = 1 to 10 { // CHECK: affine.for %{{.*}} = 1 to 10 {
Implement induction variables. Pretty print induction variable operands as %i<ssa value number>. Add support for future pretty printing of ML function arguments as %arg<ssa value number>. Induction variables are implemented by inheriting ForStmt from MLValue. ForStmt provides APIs that make this design decision invisible to the ForStmt users. This CL in combination with cl/206253643 resolves http://b/111769060. PiperOrigin-RevId: 206655937
2018-07-31 06:18:10 +08:00
"goo"() : () -> () // CHECK: "goo"() : () -> ()
} // CHECK: }
} // CHECK: }
} // CHECK: }
return // CHECK: return
} // CHECK: }
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: func @triang_loop(%{{.*}}: index, %{{.*}}: memref<?x?xi32>) {
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
func @triang_loop(%arg0: index, %arg1: memref<?x?xi32>) {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
%c = constant 0 : i32 // CHECK: %{{.*}} = constant 0 : i32
affine.for %i0 = 1 to %arg0 { // CHECK: affine.for %{{.*}} = 1 to %{{.*}} {
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
affine.for %i1 = affine_map<(d0)[]->(d0)>(%i0)[] to %arg0 { // CHECK: affine.for %{{.*}} = #map{{[0-9]+}}(%{{.*}}) to %{{.*}} {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
store %c, %arg1[%i0, %i1] : memref<?x?xi32> // CHECK: store %{{.*}}, %{{.*}}[%{{.*}}, %{{.*}}]
Implement operands for the lower and upper bounds of the for statement. This revamps implementation of the loop bounds in the ForStmt, using general representation that supports operands. The frequent case of constant bounds is supported via special access methods. This also includes: - Operand iterators for the Statement class. - OpPointer::is() method to query the class of the Operation. - Support for the bound shorthand notation parsing and printing. - Validity checks for the bound operands used as dim ids and symbols I didn't mean this CL to be so large. It just happened this way, as one thing led to another. PiperOrigin-RevId: 210204858
2018-08-25 14:38:14 +08:00
} // CHECK: }
} // CHECK: }
return // CHECK: return
} // CHECK: }
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: func @minmax_loop(%{{.*}}: index, %{{.*}}: index, %{{.*}}: memref<100xf32>) {
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
func @minmax_loop(%arg0: index, %arg1: index, %arg2: memref<100xf32>) {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: affine.for %{{.*}} = max #map{{.*}}()[%{{.*}}] to min #map{{.*}}()[%{{.*}}] {
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
affine.for %i0 = max affine_map<()[s]->(0,s-1)>()[%arg0] to min affine_map<()[s]->(100,s+1)>()[%arg1] {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: "foo"(%{{.*}}, %{{.*}}) : (memref<100xf32>, index) -> ()
Rename affineint type to index type. The name 'index' may not be perfect, but is better than the old name. Here is some justification: 1) affineint (as it is named) is not a type suitable for general computation (e.g. the multiply/adds in an integer matmul). It has undefined width and is undefined on overflow. They are used as the indices for forstmt because they are intended to be used as indexes inside the loop. 2) It can be used in both cfg and ml functions, and in cfg functions. As you mention, “symbols” are not affine, and we use affineint values for symbols. 3) Integers aren’t affine, the algorithms applied to them can be. :) 4) The only suitable use for affineint in MLIR is for indexes and dimension sizes (i.e. the bounds of those indexes). PiperOrigin-RevId: 216057974
2018-10-07 08:21:53 +08:00
"foo"(%arg2, %i0) : (memref<100xf32>, index) -> ()
Implement operands for the lower and upper bounds of the for statement. This revamps implementation of the loop bounds in the ForStmt, using general representation that supports operands. The frequent case of constant bounds is supported via special access methods. This also includes: - Operand iterators for the Statement class. - OpPointer::is() method to query the class of the Operation. - Support for the bound shorthand notation parsing and printing. - Validity checks for the bound operands used as dim ids and symbols I didn't mean this CL to be so large. It just happened this way, as one thing led to another. PiperOrigin-RevId: 210204858
2018-08-25 14:38:14 +08:00
} // CHECK: }
return // CHECK: return
} // CHECK: }
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK-LABEL: func @loop_bounds(%{{.*}}: index) {
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
func @loop_bounds(%N : index) {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = "foo"(%{{.*}}) : (index) -> index
Rename affineint type to index type. The name 'index' may not be perfect, but is better than the old name. Here is some justification: 1) affineint (as it is named) is not a type suitable for general computation (e.g. the multiply/adds in an integer matmul). It has undefined width and is undefined on overflow. They are used as the indices for forstmt because they are intended to be used as indexes inside the loop. 2) It can be used in both cfg and ml functions, and in cfg functions. As you mention, “symbols” are not affine, and we use affineint values for symbols. 3) Integers aren’t affine, the algorithms applied to them can be. :) 4) The only suitable use for affineint in MLIR is for indexes and dimension sizes (i.e. the bounds of those indexes). PiperOrigin-RevId: 216057974
2018-10-07 08:21:53 +08:00
%s = "foo"(%N) : (index) -> index
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: affine.for %{{.*}} = %{{.*}} to %{{.*}}
NFC: Rename the 'for' operation in the AffineOps dialect to 'affine.for' and set the namespace of the AffineOps dialect to 'affine'. PiperOrigin-RevId: 240165792
2019-03-26 01:14:34 +08:00
affine.for %i = %s to %N {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: affine.for %{{.*}} = #map{{[0-9]+}}(%{{.*}}) to 0
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
affine.for %j = affine_map<(d0)[]->(d0)>(%i)[] to 0 step 1 {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = affine.apply #map{{.*}}(%{{.*}}, %{{.*}})[%{{.*}}]
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
%w1 = affine.apply affine_map<(d0, d1)[s0] -> (d0+d1)> (%i, %j) [%s]
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = affine.apply #map{{.*}}(%{{.*}}, %{{.*}})[%{{.*}}]
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
%w2 = affine.apply affine_map<(d0, d1)[s0] -> (s0+1)> (%i, %j) [%s]
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: affine.for %{{.*}} = #map{{.*}}(%{{.*}}, %{{.*}})[%{{.*}}] to #map{{.*}}(%{{.*}}, %{{.*}})[%{{.*}}] {
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
affine.for %k = #bound_map1 (%w1, %i)[%N] to affine_map<(i, j)[s] -> (i + j + s)> (%w2, %j)[%s] {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: "foo"(%{{.*}}, %{{.*}}, %{{.*}}) : (index, index, index) -> ()
Rename affineint type to index type. The name 'index' may not be perfect, but is better than the old name. Here is some justification: 1) affineint (as it is named) is not a type suitable for general computation (e.g. the multiply/adds in an integer matmul). It has undefined width and is undefined on overflow. They are used as the indices for forstmt because they are intended to be used as indexes inside the loop. 2) It can be used in both cfg and ml functions, and in cfg functions. As you mention, “symbols” are not affine, and we use affineint values for symbols. 3) Integers aren’t affine, the algorithms applied to them can be. :) 4) The only suitable use for affineint in MLIR is for indexes and dimension sizes (i.e. the bounds of those indexes). PiperOrigin-RevId: 216057974
2018-10-07 08:21:53 +08:00
"foo"(%i, %j, %k) : (index, index, index)->()
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = constant 30 : index
Rename affineint type to index type. The name 'index' may not be perfect, but is better than the old name. Here is some justification: 1) affineint (as it is named) is not a type suitable for general computation (e.g. the multiply/adds in an integer matmul). It has undefined width and is undefined on overflow. They are used as the indices for forstmt because they are intended to be used as indexes inside the loop. 2) It can be used in both cfg and ml functions, and in cfg functions. As you mention, “symbols” are not affine, and we use affineint values for symbols. 3) Integers aren’t affine, the algorithms applied to them can be. :) 4) The only suitable use for affineint in MLIR is for indexes and dimension sizes (i.e. the bounds of those indexes). PiperOrigin-RevId: 216057974
2018-10-07 08:21:53 +08:00
%c = constant 30 : index
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = affine.apply #map{{.*}}(%{{.*}}, %{{.*}})
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
%u = affine.apply affine_map<(d0, d1)->(d0+d1)> (%N, %c)
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: affine.for %{{.*}} = max #map{{.*}}(%{{.*}})[%{{.*}}] to min #map{{.*}}(%{{.*}})[%{{.*}}] {
NFC: Rename the 'for' operation in the AffineOps dialect to 'affine.for' and set the namespace of the AffineOps dialect to 'affine'. PiperOrigin-RevId: 240165792
2019-03-26 01:14:34 +08:00
affine.for %l = max #bound_map2(%i)[%u] to min #bound_map2(%k)[%c] {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: "bar"(%{{.*}}) : (index) -> ()
Rename affineint type to index type. The name 'index' may not be perfect, but is better than the old name. Here is some justification: 1) affineint (as it is named) is not a type suitable for general computation (e.g. the multiply/adds in an integer matmul). It has undefined width and is undefined on overflow. They are used as the indices for forstmt because they are intended to be used as indexes inside the loop. 2) It can be used in both cfg and ml functions, and in cfg functions. As you mention, “symbols” are not affine, and we use affineint values for symbols. 3) Integers aren’t affine, the algorithms applied to them can be. :) 4) The only suitable use for affineint in MLIR is for indexes and dimension sizes (i.e. the bounds of those indexes). PiperOrigin-RevId: 216057974
2018-10-07 08:21:53 +08:00
"bar"(%l) : (index) -> ()
Implement operands for the lower and upper bounds of the for statement. This revamps implementation of the loop bounds in the ForStmt, using general representation that supports operands. The frequent case of constant bounds is supported via special access methods. This also includes: - Operand iterators for the Statement class. - OpPointer::is() method to query the class of the Operation. - Support for the bound shorthand notation parsing and printing. - Validity checks for the bound operands used as dim ids and symbols I didn't mean this CL to be so large. It just happened this way, as one thing led to another. PiperOrigin-RevId: 210204858
2018-08-25 14:38:14 +08:00
} // CHECK: }
} // CHECK: }
} // CHECK: }
} // CHECK: }
return // CHECK: return
} // CHECK: }
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK-LABEL: func @ifinst(%{{.*}}: index) {
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
func @ifinst(%N: index) {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
%c = constant 200 : index // CHECK %{{.*}} = constant 200
affine.for %i = 1 to 10 { // CHECK affine.for %{{.*}} = 1 to 10 {
affine.if #set0(%i)[%N, %c] { // CHECK affine.if #set0(%{{.*}})[%{{.*}}, %{{.*}}] {
Support for affine integer sets - introduce affine integer sets into the IR - parse and print affine integer sets (both inline or outlined) similar to affine maps - use integer set for IfStmt's conditional, and implement parsing of IfStmt's conditional - fixed an affine expr paren omission bug while one this. TODO: parse/represent/print MLValue operands to affine integer set references. PiperOrigin-RevId: 207779408
2018-08-08 05:24:38 +08:00
%x = constant 1 : i32
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = constant 1 : i32
%y = "add"(%x, %i) : (i32, index) -> i32 // CHECK: %{{.*}} = "add"(%{{.*}}, %{{.*}}) : (i32, index) -> i32
%z = "mul"(%y, %y) : (i32, i32) -> i32 // CHECK: %{{.*}} = "mul"(%{{.*}}, %{{.*}}) : (i32, i32) -> i32
Recommit: Define a AffineOps dialect as well as an AffineIfOp operation. Replace all instances of IfInst with AffineIfOp and delete IfInst. PiperOrigin-RevId: 231342063
2019-01-29 13:23:53 +08:00
} else { // CHECK } else {
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
affine.if affine_set<(i)[N] : (i - 2 >= 0, 4 - i >= 0)>(%i)[%N] { // CHECK affine.if (#set1(%{{.*}})[%{{.*}}]) {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = constant 1 : index
Recommit: Define a AffineOps dialect as well as an AffineIfOp operation. Replace all instances of IfInst with AffineIfOp and delete IfInst. PiperOrigin-RevId: 231342063
2019-01-29 13:23:53 +08:00
%u = constant 1 : index
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = affine.apply #map{{.*}}(%{{.*}}, %{{.*}})[%{{.*}}]
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
%w = affine.apply affine_map<(d0,d1)[s0] -> (d0+d1+s0)> (%i, %i) [%u]
Recommit: Define a AffineOps dialect as well as an AffineIfOp operation. Replace all instances of IfInst with AffineIfOp and delete IfInst. PiperOrigin-RevId: 231342063
2019-01-29 13:23:53 +08:00
} else { // CHECK } else {
%v = constant 3 : i32 // %c3_i32 = constant 3 : i32
}
Support for affine integer sets - introduce affine integer sets into the IR - parse and print affine integer sets (both inline or outlined) similar to affine maps - use integer set for IfStmt's conditional, and implement parsing of IfStmt's conditional - fixed an affine expr paren omission bug while one this. TODO: parse/represent/print MLValue operands to affine integer set references. PiperOrigin-RevId: 207779408
2018-08-08 05:24:38 +08:00
} // CHECK }
} // CHECK }
return // CHECK return
} // CHECK }
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK-LABEL: func @simple_ifinst(%{{.*}}: index) {
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
func @simple_ifinst(%N: index) {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
%c = constant 200 : index // CHECK %{{.*}} = constant 200
affine.for %i = 1 to 10 { // CHECK affine.for %{{.*}} = 1 to 10 {
affine.if #set0(%i)[%N, %c] { // CHECK affine.if #set0(%{{.*}})[%{{.*}}, %{{.*}}] {
Fix asan failure introduced by cl/210618122 and statement walker crash for if statements without else clause. PiperOrigin-RevId: 211186361
2018-09-01 13:33:47 +08:00
%x = constant 1 : i32
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = constant 1 : i32
%y = "add"(%x, %i) : (i32, index) -> i32 // CHECK: %{{.*}} = "add"(%{{.*}}, %{{.*}}) : (i32, index) -> i32
%z = "mul"(%y, %y) : (i32, i32) -> i32 // CHECK: %{{.*}} = "mul"(%{{.*}}, %{{.*}}) : (i32, i32) -> i32
Fix asan failure introduced by cl/210618122 and statement walker crash for if statements without else clause. PiperOrigin-RevId: 211186361
2018-09-01 13:33:47 +08:00
} // CHECK }
} // CHECK }
return // CHECK return
} // CHECK }
Switch the comment syntax from ; to // comments as discussed on Friday. There is no strong reason to prefer one or the other, but // is nice for consistency given the rest of the compiler is written in C++. PiperOrigin-RevId: 204628476
2018-07-15 14:06:24 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @attributes() {
func @attributes() {
Switch the comment syntax from ; to // comments as discussed on Friday. There is no strong reason to prefer one or the other, but // is nice for consistency given the rest of the compiler is written in C++. PiperOrigin-RevId: 204628476
2018-07-15 14:06:24 +08:00
// CHECK: "foo"()
Initial support for operands and results and SSA constructs, first on the instruction side of the house. This has a number of limitations, including that we are still dropping operands on the floor in the parser. Also, most of the convenience methods aren't wired up yet. This is enough to get result type lists round tripping through. PiperOrigin-RevId: 205148223
2018-07-19 06:31:25 +08:00
"foo"(){} : ()->()
Add parsing for attributes and attibutes on operations. Add IR representation for attributes on operations. Split Operation out from OperationInst so it can be shared with OperationStmt one day. PiperOrigin-RevId: 203325366
2018-07-05 11:45:39 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo"() {a = 1 : i64, b = -423 : i64, c = [true, false], d = 1.600000e+01 : f64} : () -> ()
"foo"() {a = 1, b = -423, c = [true, false], d = 16.0 } : () -> ()
Add parsing for attributes and attibutes on operations. Add IR representation for attributes on operations. Split Operation out from OperationInst so it can be shared with OperationStmt one day. PiperOrigin-RevId: 203325366
2018-07-05 11:45:39 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo"() {map1 = #map{{[0-9]+}}}
"foo"() {map1 = #map1} : () -> ()
Support for AffineMapAttr. PiperOrigin-RevId: 205157390
2018-07-19 07:29:21 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo"() {map2 = #map{{[0-9]+}}}
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
"foo"() {map2 = affine_map<(d0, d1, d2) -> (d0, d1, d2)>} : () -> ()
Support for AffineMapAttr. PiperOrigin-RevId: 205157390
2018-07-19 07:29:21 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo"() {map12 = [#map{{[0-9]+}}, #map{{[0-9]+}}]}
"foo"() {map12 = [#map1, #map2]} : () -> ()
Support for AffineMapAttr. PiperOrigin-RevId: 205157390
2018-07-19 07:29:21 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo"() {set1 = #set{{[0-9]+}}}
"foo"() {set1 = #set1} : () -> ()
Introduce integer set attribute - add IntegerSetAttr to Attributes; add parsing and other support for it (builder, etc.). PiperOrigin-RevId: 218804579
2018-10-26 13:13:03 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo"() {set2 = #set{{[0-9]+}}}
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
"foo"() {set2 = affine_set<(d0, d1, d2) : (d0 >= 0, d1 >= 0, d2 - d1 == 0)>} : () -> ()
Introduce integer set attribute - add IntegerSetAttr to Attributes; add parsing and other support for it (builder, etc.). PiperOrigin-RevId: 218804579
2018-10-26 13:13:03 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo"() {set12 = [#set{{[0-9]+}}, #set{{[0-9]+}}]}
"foo"() {set12 = [#set1, #set2]} : () -> ()
Introduce integer set attribute - add IntegerSetAttr to Attributes; add parsing and other support for it (builder, etc.). PiperOrigin-RevId: 218804579
2018-10-26 13:13:03 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo"() {dictionary = {bool = true, fn = @ifinst}}
"foo"() {dictionary = {bool = true, fn = @ifinst}} : () -> ()
Abstract the internal storage of the NamedAttributeList into a new attribute, DictionaryAttr. This attribute maintains a sorted list of NamedAttributes. This will allow for operations/functions to maintain sub dictionaries of attributes. The syntax is the same as top level attribute dictionaries: {sub_dictionary: {fn: @someFn, boolAttr: true}} -- PiperOrigin-RevId: 250898950
2019-06-01 00:24:48 +08:00
// Check that the dictionary attribute elements are sorted.
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo"() {dictionary = {bar = false, bool = true, fn = @ifinst}}
"foo"() {dictionary = {fn = @ifinst, bar = false, bool = true}} : () -> ()
Abstract the internal storage of the NamedAttributeList into a new attribute, DictionaryAttr. This attribute maintains a sorted list of NamedAttributes. This will allow for operations/functions to maintain sub dictionaries of attributes. The syntax is the same as top level attribute dictionaries: {sub_dictionary: {fn: @someFn, boolAttr: true}} -- PiperOrigin-RevId: 250898950
2019-06-01 00:24:48 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo"() {d = 1.000000e-09 : f64, func = [], i123 = 7 : i64, if = "foo"} : () -> ()
"foo"() {if = "foo", func = [], i123 = 7, d = 1.e-9} : () -> ()
Add parsing for attributes and attibutes on operations. Add IR representation for attributes on operations. Split Operation out from OperationInst so it can be shared with OperationStmt one day. PiperOrigin-RevId: 203325366
2018-07-05 11:45:39 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo"() {fn = @attributes, if = @ifinst} : () -> ()
"foo"() {fn = @attributes, if = @ifinst} : () -> ()
Print non-default attribute types in optional attr dictionary In optional attribute dictionary used, among others, in the generic form of the ops, attribute types for integers and floats are omitted. This could lead to inconsistencies when round-tripping the IR, in particular the attributes are created with incorrect types after parsing (integers default to i64, floats default to f64). Provide API to emit a trailing type after the attribute for integers and floats. Use it while printing the optional attribute dictionary. Omitting types for i64 and f64 is a pragmatic decision that minimizes changes in tests. We may want to reconsider in the future and always print types of attributes in the generic form. PiperOrigin-RevId: 232480116
2019-02-05 23:12:46 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo"() {int = 0 : i42} : () -> ()
"foo"() {int = 0 : i42} : () -> ()
Add the ability to have "Ops" defined as small C++ classes, with some nice properties: - They allow type checked dynamic casting from their base Operation. - They allow nice accessors for C++ clients, e.g. a "getIndex()" method on 'dim' that returns an unsigned. - They work with both OperationInst/OperationStmt (once OperationStmt is implemented). - They get custom printing logic. They will eventually get custom parsing, verifier, and builder logic as well. - Out of tree clients can register their own operation set without having to change MLIR core, e.g. for TensorFlow or custom target instructions. This registers addf and dim as examples. PiperOrigin-RevId: 203382993
2018-07-06 00:12:11 +08:00
return
Add parsing for attributes and attibutes on operations. Add IR representation for attributes on operations. Split Operation out from OperationInst so it can be shared with OperationStmt one day. PiperOrigin-RevId: 203325366
2018-07-05 11:45:39 +08:00
}
Add support for multiple results to the printer/parser, add support for forward references to the parser, add initial support for SSA use-list iteration and RAUW. PiperOrigin-RevId: 205484031
2018-07-21 09:41:34 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @ssa_values() -> (i16, i8) {
func @ssa_values() -> (i16, i8) {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}}:2 = "foo"() : () -> (i1, i17)
Change the muli-return syntax for operations. The name of the operation result now contains the number of results that it refers to if the number of results is greater than 1. Example: %call:2 = call @multi_return() : () -> (f32, i32) use(%calltensorflow/mlir#0, %calltensorflow/mlir#1) This cl also adds parser support for uniquely named result values. This means that a test writer can now write something like: %foo, %bar = call @multi_return() : () -> (f32, i32) use(%foo, %bar) Note: The printer will still print the collapsed form. PiperOrigin-RevId: 240860058
2019-03-29 05:58:52 +08:00
%0:2 = "foo"() : () -> (i1, i17)
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
br ^bb2
Add support for multiple results to the printer/parser, add support for forward references to the parser, add initial support for SSA use-list iteration and RAUW. PiperOrigin-RevId: 205484031
2018-07-21 09:41:34 +08:00
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb1: // CHECK: ^bb1: // pred: ^bb2
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}}:2 = "baz"(%{{.*}}#1, %{{.*}}#0, %{{.*}}#1) : (f32, i11, i17) -> (i16, i8)
Change the muli-return syntax for operations. The name of the operation result now contains the number of results that it refers to if the number of results is greater than 1. Example: %call:2 = call @multi_return() : () -> (f32, i32) use(%calltensorflow/mlir#0, %calltensorflow/mlir#1) This cl also adds parser support for uniquely named result values. This means that a test writer can now write something like: %foo, %bar = call @multi_return() : () -> (f32, i32) use(%foo, %bar) Note: The printer will still print the collapsed form. PiperOrigin-RevId: 240860058
2019-03-29 05:58:52 +08:00
%1:2 = "baz"(%2#1, %2#0, %0#1) : (f32, i11, i17) -> (i16, i8)
Allow 'constant' op to work with affineint, add some accessors, rearrange testsuite a bit. PiperOrigin-RevId: 205852871
2018-07-25 01:41:30 +08:00
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: return %{{.*}}#0, %{{.*}}#1 : i16, i8
Switch return instruction to take its operand list separated from its type list, for consistency with the rest of the language. Consolidate some parsing logic, add operand iterators to BranchInst. PiperOrigin-RevId: 205699457
2018-07-24 02:56:17 +08:00
return %1#0, %1#1 : i16, i8
Add support for multiple results to the printer/parser, add support for forward references to the parser, add initial support for SSA use-list iteration and RAUW. PiperOrigin-RevId: 205484031
2018-07-21 09:41:34 +08:00
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb2: // CHECK: ^bb2: // pred: ^bb0
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}}:2 = "bar"(%{{.*}}#0, %{{.*}}#1) : (i1, i17) -> (i11, f32)
Change the muli-return syntax for operations. The name of the operation result now contains the number of results that it refers to if the number of results is greater than 1. Example: %call:2 = call @multi_return() : () -> (f32, i32) use(%calltensorflow/mlir#0, %calltensorflow/mlir#1) This cl also adds parser support for uniquely named result values. This means that a test writer can now write something like: %foo, %bar = call @multi_return() : () -> (f32, i32) use(%foo, %bar) Note: The printer will still print the collapsed form. PiperOrigin-RevId: 240860058
2019-03-29 05:58:52 +08:00
%2:2 = "bar"(%0#0, %0#1) : (i1, i17) -> (i11, f32)
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
br ^bb1
Implement support for branch instruction operands. PiperOrigin-RevId: 205666777
2018-07-23 23:42:19 +08:00
}
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @bbargs() -> (i16, i8) {
func @bbargs() -> (i16, i8) {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}}:2 = "foo"() : () -> (i1, i17)
Change the muli-return syntax for operations. The name of the operation result now contains the number of results that it refers to if the number of results is greater than 1. Example: %call:2 = call @multi_return() : () -> (f32, i32) use(%calltensorflow/mlir#0, %calltensorflow/mlir#1) This cl also adds parser support for uniquely named result values. This means that a test writer can now write something like: %foo, %bar = call @multi_return() : () -> (f32, i32) use(%foo, %bar) Note: The printer will still print the collapsed form. PiperOrigin-RevId: 240860058
2019-03-29 05:58:52 +08:00
%0:2 = "foo"() : () -> (i1, i17)
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
br ^bb1(%0#1, %0#0 : i17, i1)
Implement support for branch instruction operands. PiperOrigin-RevId: 205666777
2018-07-23 23:42:19 +08:00
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
^bb1(%x: i17, %y: i1): // CHECK: ^bb1(%{{.*}}: i17, %{{.*}}: i1):
// CHECK: %{{.*}}:2 = "baz"(%{{.*}}, %{{.*}}, %{{.*}}#1) : (i17, i1, i17) -> (i16, i8)
Change the muli-return syntax for operations. The name of the operation result now contains the number of results that it refers to if the number of results is greater than 1. Example: %call:2 = call @multi_return() : () -> (f32, i32) use(%calltensorflow/mlir#0, %calltensorflow/mlir#1) This cl also adds parser support for uniquely named result values. This means that a test writer can now write something like: %foo, %bar = call @multi_return() : () -> (f32, i32) use(%foo, %bar) Note: The printer will still print the collapsed form. PiperOrigin-RevId: 240860058
2019-03-29 05:58:52 +08:00
%1:2 = "baz"(%x, %y, %0#1) : (i17, i1, i17) -> (i16, i8)
Switch return instruction to take its operand list separated from its type list, for consistency with the rest of the language. Consolidate some parsing logic, add operand iterators to BranchInst. PiperOrigin-RevId: 205699457
2018-07-24 02:56:17 +08:00
return %1#0, %1#1 : i16, i8
Implement support for branch instruction operands. PiperOrigin-RevId: 205666777
2018-07-23 23:42:19 +08:00
}
[mlir] Implement conditional branch This looks heavyweight but most of the code is in the massive number of operand accessors! We need to be able to iterate over all operands to the condbr (all live-outs) but also just the true/just the false operands too. PiperOrigin-RevId: 205897704
2018-07-25 06:01:27 +08:00
Support verbose parsing and printing of terminator operations Originally, terminators were special kinds of operation and could not be extended by dialects. Only builtin terminators were supported and they had custom parsers and printers. Currently, "terminator" is a property of an operation, making it possible for dialects to define custom terminators. However, verbose forms of operation syntax were not designed to support terminators that may have a list of successors (each successor contains a block name and an optional operand list). Calling printDefaultOp on a terminator drops all successor information. Dialects are thus required to provide custom parsers and printers for their terminators. Introduce the syntax for the list of successors in the verbose from of the operation. Add support for printing and parsing verbose operations with successors. Note that this does not yet add support for unregistered terminators since "terminator" is a property stored in AsbtractOperation and therefore is only available for registered operations that have an instance of AbstractOperation. Add tests for verbose parsing. It is currently impossible to test round-trip for verbose terminators because none of the known dialects use verbose syntax for printing terminators by default, however the printer was exercised on the LLVM IR dialect prototype. PiperOrigin-RevId: 228566453
2019-01-10 04:28:30 +08:00
// CHECK-LABEL: func @verbose_terminators() -> (i1, i17)
func @verbose_terminators() -> (i1, i17) {
Change the muli-return syntax for operations. The name of the operation result now contains the number of results that it refers to if the number of results is greater than 1. Example: %call:2 = call @multi_return() : () -> (f32, i32) use(%calltensorflow/mlir#0, %calltensorflow/mlir#1) This cl also adds parser support for uniquely named result values. This means that a test writer can now write something like: %foo, %bar = call @multi_return() : () -> (f32, i32) use(%foo, %bar) Note: The printer will still print the collapsed form. PiperOrigin-RevId: 240860058
2019-03-29 05:58:52 +08:00
%0:2 = "foo"() : () -> (i1, i17)
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: br ^bb1(%{{.*}}#0, %{{.*}}#1 : i1, i17)
[mlir] Remove successor operands from the Operation class Summary: This revision removes all of the functionality related to successor operands on the core Operation class. This greatly simplifies a lot of handling of operands, as well as successors. For example, DialectConversion no longer needs a special "matchAndRewrite" for branching terminator operations.(Note, the existing method was also broken for operations with variadic successors!!) This also enables terminator operations to define their own relationships with successor arguments, instead of the hardcoded "pass-through" behavior that exists today. Differential Revision: https://reviews.llvm.org/D75318
2020-03-06 04:48:28 +08:00
"std.br"(%0#0, %0#1)[^bb1] : (i1, i17) -> ()
Support verbose parsing and printing of terminator operations Originally, terminators were special kinds of operation and could not be extended by dialects. Only builtin terminators were supported and they had custom parsers and printers. Currently, "terminator" is a property of an operation, making it possible for dialects to define custom terminators. However, verbose forms of operation syntax were not designed to support terminators that may have a list of successors (each successor contains a block name and an optional operand list). Calling printDefaultOp on a terminator drops all successor information. Dialects are thus required to provide custom parsers and printers for their terminators. Introduce the syntax for the list of successors in the verbose from of the operation. Add support for printing and parsing verbose operations with successors. Note that this does not yet add support for unregistered terminators since "terminator" is a property stored in AsbtractOperation and therefore is only available for registered operations that have an instance of AbstractOperation. Add tests for verbose parsing. It is currently impossible to test round-trip for verbose terminators because none of the known dialects use verbose syntax for printing terminators by default, however the printer was exercised on the LLVM IR dialect prototype. PiperOrigin-RevId: 228566453
2019-01-10 04:28:30 +08:00
^bb1(%x : i1, %y : i17):
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: cond_br %{{.*}}, ^bb2(%{{.*}} : i17), ^bb3(%{{.*}}, %{{.*}} : i1, i17)
[mlir] Remove successor operands from the Operation class Summary: This revision removes all of the functionality related to successor operands on the core Operation class. This greatly simplifies a lot of handling of operands, as well as successors. For example, DialectConversion no longer needs a special "matchAndRewrite" for branching terminator operations.(Note, the existing method was also broken for operations with variadic successors!!) This also enables terminator operations to define their own relationships with successor arguments, instead of the hardcoded "pass-through" behavior that exists today. Differential Revision: https://reviews.llvm.org/D75318
2020-03-06 04:48:28 +08:00
"std.cond_br"(%x, %y, %x, %y) [^bb2, ^bb3] {operand_segment_sizes = dense<[1, 1, 2]>: vector<3xi32>} : (i1, i17, i1, i17) -> ()
Support verbose parsing and printing of terminator operations Originally, terminators were special kinds of operation and could not be extended by dialects. Only builtin terminators were supported and they had custom parsers and printers. Currently, "terminator" is a property of an operation, making it possible for dialects to define custom terminators. However, verbose forms of operation syntax were not designed to support terminators that may have a list of successors (each successor contains a block name and an optional operand list). Calling printDefaultOp on a terminator drops all successor information. Dialects are thus required to provide custom parsers and printers for their terminators. Introduce the syntax for the list of successors in the verbose from of the operation. Add support for printing and parsing verbose operations with successors. Note that this does not yet add support for unregistered terminators since "terminator" is a property stored in AsbtractOperation and therefore is only available for registered operations that have an instance of AbstractOperation. Add tests for verbose parsing. It is currently impossible to test round-trip for verbose terminators because none of the known dialects use verbose syntax for printing terminators by default, however the printer was exercised on the LLVM IR dialect prototype. PiperOrigin-RevId: 228566453
2019-01-10 04:28:30 +08:00
^bb2(%a : i17):
[mlir] Refactor BoolAttr to be a special case of IntegerAttr This simplifies a lot of handling of BoolAttr/IntegerAttr. For example, a lot of places currently have to handle both IntegerAttr and BoolAttr. In other places, a decision is made to pick one which can lead to surprising results for users. For example, DenseElementsAttr currently uses BoolAttr for i1 even if the user initialized it with an Array of i1 IntegerAttrs. Differential Revision: https://reviews.llvm.org/D81047
2020-06-03 09:20:38 +08:00
%true = constant true
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: return %{{.*}}, %{{.*}} : i1, i17
Set the namespace of the StandardOps dialect to "std", but add a special case to the parser to allow parsing standard operations without the "std" prefix. This will now allow for the standard dialect to be looked up dynamically by name. PiperOrigin-RevId: 236493865
2019-03-03 10:03:03 +08:00
"std.return"(%true, %a) : (i1, i17) -> ()
Support verbose parsing and printing of terminator operations Originally, terminators were special kinds of operation and could not be extended by dialects. Only builtin terminators were supported and they had custom parsers and printers. Currently, "terminator" is a property of an operation, making it possible for dialects to define custom terminators. However, verbose forms of operation syntax were not designed to support terminators that may have a list of successors (each successor contains a block name and an optional operand list). Calling printDefaultOp on a terminator drops all successor information. Dialects are thus required to provide custom parsers and printers for their terminators. Introduce the syntax for the list of successors in the verbose from of the operation. Add support for printing and parsing verbose operations with successors. Note that this does not yet add support for unregistered terminators since "terminator" is a property stored in AsbtractOperation and therefore is only available for registered operations that have an instance of AbstractOperation. Add tests for verbose parsing. It is currently impossible to test round-trip for verbose terminators because none of the known dialects use verbose syntax for printing terminators by default, however the printer was exercised on the LLVM IR dialect prototype. PiperOrigin-RevId: 228566453
2019-01-10 04:28:30 +08:00
^bb3(%b : i1, %c : i17):
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: return %{{.*}}, %{{.*}} : i1, i17
Set the namespace of the StandardOps dialect to "std", but add a special case to the parser to allow parsing standard operations without the "std" prefix. This will now allow for the standard dialect to be looked up dynamically by name. PiperOrigin-RevId: 236493865
2019-03-03 10:03:03 +08:00
"std.return"(%b, %c) : (i1, i17) -> ()
Support verbose parsing and printing of terminator operations Originally, terminators were special kinds of operation and could not be extended by dialects. Only builtin terminators were supported and they had custom parsers and printers. Currently, "terminator" is a property of an operation, making it possible for dialects to define custom terminators. However, verbose forms of operation syntax were not designed to support terminators that may have a list of successors (each successor contains a block name and an optional operand list). Calling printDefaultOp on a terminator drops all successor information. Dialects are thus required to provide custom parsers and printers for their terminators. Introduce the syntax for the list of successors in the verbose from of the operation. Add support for printing and parsing verbose operations with successors. Note that this does not yet add support for unregistered terminators since "terminator" is a property stored in AsbtractOperation and therefore is only available for registered operations that have an instance of AbstractOperation. Add tests for verbose parsing. It is currently impossible to test round-trip for verbose terminators because none of the known dialects use verbose syntax for printing terminators by default, however the printer was exercised on the LLVM IR dialect prototype. PiperOrigin-RevId: 228566453
2019-01-10 04:28:30 +08:00
}
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @condbr_simple
func @condbr_simple() -> (i32) {
[mlir] Implement conditional branch This looks heavyweight but most of the code is in the massive number of operand accessors! We need to be able to iterate over all operands to the condbr (all live-outs) but also just the true/just the false operands too. PiperOrigin-RevId: 205897704
2018-07-25 06:01:27 +08:00
%cond = "foo"() : () -> i1
%a = "bar"() : () -> i32
%b = "bar"() : () -> i64
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: cond_br %{{.*}}, ^bb1(%{{.*}} : i32), ^bb2(%{{.*}} : i64)
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
cond_br %cond, ^bb1(%a : i32), ^bb2(%b : i64)
[mlir] Implement conditional branch This looks heavyweight but most of the code is in the massive number of operand accessors! We need to be able to iterate over all operands to the condbr (all live-outs) but also just the true/just the false operands too. PiperOrigin-RevId: 205897704
2018-07-25 06:01:27 +08:00
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK: ^bb1({{.*}}: i32): // pred: ^bb0
^bb1(%x : i32):
br ^bb2(%b: i64)
[mlir] Implement conditional branch This looks heavyweight but most of the code is in the massive number of operand accessors! We need to be able to iterate over all operands to the condbr (all live-outs) but also just the true/just the false operands too. PiperOrigin-RevId: 205897704
2018-07-25 06:01:27 +08:00
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
// CHECK: ^bb2({{.*}}: i64): // 2 preds: ^bb0, ^bb1
^bb2(%y : i64):
[mlir] Implement conditional branch This looks heavyweight but most of the code is in the massive number of operand accessors! We need to be able to iterate over all operands to the condbr (all live-outs) but also just the true/just the false operands too. PiperOrigin-RevId: 205897704
2018-07-25 06:01:27 +08:00
%z = "foo"() : () -> i32
return %z : i32
}
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @condbr_moarargs
func @condbr_moarargs() -> (i32) {
[mlir] Implement conditional branch This looks heavyweight but most of the code is in the massive number of operand accessors! We need to be able to iterate over all operands to the condbr (all live-outs) but also just the true/just the false operands too. PiperOrigin-RevId: 205897704
2018-07-25 06:01:27 +08:00
%cond = "foo"() : () -> i1
%a = "bar"() : () -> i32
%b = "bar"() : () -> i64
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: cond_br %{{.*}}, ^bb1(%{{.*}}, %{{.*}} : i32, i64), ^bb2(%{{.*}}, %{{.*}}, %{{.*}} : i64, i32, i32)
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
cond_br %cond, ^bb1(%a, %b : i32, i64), ^bb2(%b, %a, %a : i64, i32, i32)
[mlir] Implement conditional branch This looks heavyweight but most of the code is in the massive number of operand accessors! We need to be able to iterate over all operands to the condbr (all live-outs) but also just the true/just the false operands too. PiperOrigin-RevId: 205897704
2018-07-25 06:01:27 +08:00
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb1(%x : i32, %y : i64):
[mlir] Implement conditional branch This looks heavyweight but most of the code is in the massive number of operand accessors! We need to be able to iterate over all operands to the condbr (all live-outs) but also just the true/just the false operands too. PiperOrigin-RevId: 205897704
2018-07-25 06:01:27 +08:00
return %x : i32
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb2(%x2 : i64, %y2 : i32, %z2 : i32):
[mlir] Implement conditional branch This looks heavyweight but most of the code is in the massive number of operand accessors! We need to be able to iterate over all operands to the condbr (all live-outs) but also just the true/just the false operands too. PiperOrigin-RevId: 205897704
2018-07-25 06:01:27 +08:00
%z = "foo"() : () -> i32
return %z : i32
}
Use SFINAE to generalize << overloads, give 'constant' a pretty form, generalize the asmprinters handling of pretty names to allow arbitrary sugar to be dumped on various constructs. Give CFG function arguments nice "arg0" names like MLFunctions get, and give constant integers pretty names like %c37 for a constant 377 PiperOrigin-RevId: 206953080
2018-08-02 01:43:18 +08:00
// Test pretty printing of constant names.
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @constants
func @constants() -> (i32, i23, i23, i1, i1) {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = constant 42 : i32
Use SFINAE to generalize << overloads, give 'constant' a pretty form, generalize the asmprinters handling of pretty names to allow arbitrary sugar to be dumped on various constructs. Give CFG function arguments nice "arg0" names like MLFunctions get, and give constant integers pretty names like %c37 for a constant 377 PiperOrigin-RevId: 206953080
2018-08-02 01:43:18 +08:00
%x = constant 42 : i32
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = constant 17 : i23
Use SFINAE to generalize << overloads, give 'constant' a pretty form, generalize the asmprinters handling of pretty names to allow arbitrary sugar to be dumped on various constructs. Give CFG function arguments nice "arg0" names like MLFunctions get, and give constant integers pretty names like %c37 for a constant 377 PiperOrigin-RevId: 206953080
2018-08-02 01:43:18 +08:00
%y = constant 17 : i23
// This is a redundant definition of 17, the asmprinter gives it a unique name
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = constant 17 : i23
Use SFINAE to generalize << overloads, give 'constant' a pretty form, generalize the asmprinters handling of pretty names to allow arbitrary sugar to be dumped on various constructs. Give CFG function arguments nice "arg0" names like MLFunctions get, and give constant integers pretty names like %c37 for a constant 377 PiperOrigin-RevId: 206953080
2018-08-02 01:43:18 +08:00
%z = constant 17 : i23
[mlir] Refactor BoolAttr to be a special case of IntegerAttr This simplifies a lot of handling of BoolAttr/IntegerAttr. For example, a lot of places currently have to handle both IntegerAttr and BoolAttr. In other places, a decision is made to pick one which can lead to surprising results for users. For example, DenseElementsAttr currently uses BoolAttr for i1 even if the user initialized it with an Array of i1 IntegerAttrs. Differential Revision: https://reviews.llvm.org/D81047
2020-06-03 09:20:38 +08:00
// CHECK: %{{.*}} = constant true
%t = constant true
// CHECK: %{{.*}} = constant false
%f = constant false
Have the asmprinter give true/false constants nice names, add a dump/print method to SSAValue. PiperOrigin-RevId: 207193088
2018-08-03 08:16:58 +08:00
Disallow hexadecimal literals in type declarations Existing IR syntax is ambiguous in type declarations in presence of zero sizes. In particular, `0x1` in the type size can be interpreted as either a hexadecimal literal corresponding to 1, or as two distinct decimal literals separated by an `x` for sizes. Furthermore, the shape `<0xi32>` fails lexing because it is expected to be an integer literal. Fix the lexer to treat `0xi32` as an integer literal `0` followed by a bare identifier `xi32` (look one character ahead and early return instead of erroring out). Disallow hexadecimal literals in type declarations and forcibly split the token into multiple parts while parsing the type. Note that the splitting trick has been already present to separate the element type from the preceding `x` character. PiperOrigin-RevId: 232880373
2019-02-08 00:36:50 +08:00
// The trick to parse type declarations should not interfere with hex
// literals.
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = constant 3890 : i32
Disallow hexadecimal literals in type declarations Existing IR syntax is ambiguous in type declarations in presence of zero sizes. In particular, `0x1` in the type size can be interpreted as either a hexadecimal literal corresponding to 1, or as two distinct decimal literals separated by an `x` for sizes. Furthermore, the shape `<0xi32>` fails lexing because it is expected to be an integer literal. Fix the lexer to treat `0xi32` as an integer literal `0` followed by a bare identifier `xi32` (look one character ahead and early return instead of erroring out). Disallow hexadecimal literals in type declarations and forcibly split the token into multiple parts while parsing the type. Note that the splitting trick has been already present to separate the element type from the preceding `x` character. PiperOrigin-RevId: 232880373
2019-02-08 00:36:50 +08:00
%h = constant 0xf32 : i32
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: return %{{.*}}, %{{.*}}, %{{.*}}, %{{.*}}, %{{.*}}
Have the asmprinter give true/false constants nice names, add a dump/print method to SSAValue. PiperOrigin-RevId: 207193088
2018-08-03 08:16:58 +08:00
return %x, %y, %z, %t, %f : i32, i23, i23, i1, i1
Use SFINAE to generalize << overloads, give 'constant' a pretty form, generalize the asmprinters handling of pretty names to allow arbitrary sugar to be dumped on various constructs. Give CFG function arguments nice "arg0" names like MLFunctions get, and give constant integers pretty names like %c37 for a constant 377 PiperOrigin-RevId: 206953080
2018-08-02 01:43:18 +08:00
}
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @typeattr
func @typeattr() -> () {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb0:
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo"() {bar = tensor<*xf32>} : () -> ()
"foo"(){bar = tensor<*xf32>} : () -> ()
[mlir] Add a TypeAttr class, allow type attributes PiperOrigin-RevId: 207235956
2018-08-03 16:54:46 +08:00
return
}
[mlir] Allow C-style escapes in Lexer This patch passes the raw, unescaped value through to the rest of the stack. Partial escaping is a total pain to deal with, so we either need to implement escaping properly (ideally using a third party library like absl, I don't think LLVM has one that can handle the proper gamut of escape codes) or don't escape. I chose the latter for this patch. PiperOrigin-RevId: 208608945
2018-08-14 16:16:45 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @stringquote
func @stringquote() -> () {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb0:
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo"() {bar = "a\22quoted\22string"} : () -> ()
"foo"(){bar = "a\"quoted\"string"} : () -> ()
Allow attaching a type to StringAttr. Some dialects allow for string types, and this allows for reusing StringAttr for constants of these types. PiperOrigin-RevId: 255413948
2019-06-28 00:12:19 +08:00
// CHECK-NEXT: "typed_string" : !foo.string
"foo"(){bar = "typed_string" : !foo.string} : () -> ()
[mlir] Allow C-style escapes in Lexer This patch passes the raw, unescaped value through to the rest of the stack. Partial escaping is a total pain to deal with, so we either need to implement escaping properly (ideally using a third party library like absl, I don't think LLVM has one that can handle the proper gamut of escape codes) or don't escape. I chose the latter for this patch. PiperOrigin-RevId: 208608945
2018-08-14 16:16:45 +08:00
return
}
Escape and unescape strings in the parser and printer so they can roundtrip, print floating point in a structured form that we know can round trip, enumerate attributes in the visitor so we print affine mapping attributes symbolically (the majority of the testcase updates). We still have an issue where the hexadecimal floating point syntax is reparsed as an integer, but that can evolve in subsequent patches. PiperOrigin-RevId: 208828876
2018-08-16 00:09:54 +08:00
Add support for Unit Attributes. A unit attribute is an attribute that represents a value of `unit` type. The `unit` type allows only one value forming a singleton set. This attribute value is used to represent attributes that only have meaning from their existence. One example of such an attribute could be the `swift.self` attribute. This attribute indicates that a function parameter is the self/context parameter. It could be represented as a boolean attribute(true or false), but a value of false doesn't really bring any value. The parameter either is the self/context or it isn't. ```mlir {.mlir} // A unit attribute defined with the `unit` value specifier. func @verbose_form(i1 {unitAttr : unit}) // A unit attribute can also be defined without the `unit` value specifier. func @simple_form(i1 {unitAttr}) ``` -- PiperOrigin-RevId: 245254045
2019-04-26 00:56:09 +08:00
// CHECK-LABEL: func @unitAttrs
func @unitAttrs() -> () {
NFC: Elide the value of a UnitAttr within nested attribute dictionaries. This matches the behavior of the top level attribute dictionary. PiperOrigin-RevId: 275879828
2019-10-22 02:01:38 +08:00
// CHECK-NEXT: "foo"() {unitAttr}
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
"foo"() {unitAttr = unit} : () -> ()
Add support for Unit Attributes. A unit attribute is an attribute that represents a value of `unit` type. The `unit` type allows only one value forming a singleton set. This attribute value is used to represent attributes that only have meaning from their existence. One example of such an attribute could be the `swift.self` attribute. This attribute indicates that a function parameter is the self/context parameter. It could be represented as a boolean attribute(true or false), but a value of false doesn't really bring any value. The parameter either is the self/context or it isn't. ```mlir {.mlir} // A unit attribute defined with the `unit` value specifier. func @verbose_form(i1 {unitAttr : unit}) // A unit attribute can also be defined without the `unit` value specifier. func @simple_form(i1 {unitAttr}) ``` -- PiperOrigin-RevId: 245254045
2019-04-26 00:56:09 +08:00
NFC: Elide the value of a UnitAttr within nested attribute dictionaries. This matches the behavior of the top level attribute dictionary. PiperOrigin-RevId: 275879828
2019-10-22 02:01:38 +08:00
// CHECK-NEXT: "foo"() {unitAttr}
Add support for Unit Attributes. A unit attribute is an attribute that represents a value of `unit` type. The `unit` type allows only one value forming a singleton set. This attribute value is used to represent attributes that only have meaning from their existence. One example of such an attribute could be the `swift.self` attribute. This attribute indicates that a function parameter is the self/context parameter. It could be represented as a boolean attribute(true or false), but a value of false doesn't really bring any value. The parameter either is the self/context or it isn't. ```mlir {.mlir} // A unit attribute defined with the `unit` value specifier. func @verbose_form(i1 {unitAttr : unit}) // A unit attribute can also be defined without the `unit` value specifier. func @simple_form(i1 {unitAttr}) ``` -- PiperOrigin-RevId: 245254045
2019-04-26 00:56:09 +08:00
"foo"() {unitAttr} : () -> ()
NFC: Elide the value of a UnitAttr within nested attribute dictionaries. This matches the behavior of the top level attribute dictionary. PiperOrigin-RevId: 275879828
2019-10-22 02:01:38 +08:00
// CHECK-NEXT: "foo"() {nested = {unitAttr}}
"foo"() {nested = {unitAttr}} : () -> ()
Add support for Unit Attributes. A unit attribute is an attribute that represents a value of `unit` type. The `unit` type allows only one value forming a singleton set. This attribute value is used to represent attributes that only have meaning from their existence. One example of such an attribute could be the `swift.self` attribute. This attribute indicates that a function parameter is the self/context parameter. It could be represented as a boolean attribute(true or false), but a value of false doesn't really bring any value. The parameter either is the self/context or it isn't. ```mlir {.mlir} // A unit attribute defined with the `unit` value specifier. func @verbose_form(i1 {unitAttr : unit}) // A unit attribute can also be defined without the `unit` value specifier. func @simple_form(i1 {unitAttr}) ``` -- PiperOrigin-RevId: 245254045
2019-04-26 00:56:09 +08:00
return
}
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @floatAttrs
func @floatAttrs() -> () {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb0:
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo"() {a = 4.000000e+00 : f64, b = 2.000000e+00 : f64, c = 7.100000e+00 : f64, d = -0.000000e+00 : f64} : () -> ()
"foo"(){a = 4.0, b = 2.0, c = 7.1, d = -0.0} : () -> ()
Escape and unescape strings in the parser and printer so they can roundtrip, print floating point in a structured form that we know can round trip, enumerate attributes in the visitor so we print affine mapping attributes symbolically (the majority of the testcase updates). We still have an issue where the hexadecimal floating point syntax is reparsed as an integer, but that can evolve in subsequent patches. PiperOrigin-RevId: 208828876
2018-08-16 00:09:54 +08:00
return
Add custom lilith script. Add custom lilith script with paths set to MLIR tools directories to simplify lit test. PiperOrigin-RevId: 209486232
2018-08-21 05:37:39 +08:00
}
Add function attributes for ExtFunction, CFGFunction and MLFunction. PiperOrigin-RevId: 213540509
2018-09-19 07:36:26 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @externalfuncattr
func @externalfuncattr() -> ()
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: attributes {dialect.a = "a\22quoted\22string", dialect.b = 4.000000e+00 : f64, dialect.c = tensor<*xf32>}
attributes {dialect.a = "a\"quoted\"string", dialect.b = 4.0, dialect.c = tensor<*xf32>}
Add function attributes for ExtFunction, CFGFunction and MLFunction. PiperOrigin-RevId: 213540509
2018-09-19 07:36:26 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @funcattrempty
func @funcattrempty() -> ()
Add function attributes for ExtFunction, CFGFunction and MLFunction. PiperOrigin-RevId: 213540509
2018-09-19 07:36:26 +08:00
attributes {}
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @funcattr
func @funcattr() -> ()
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: attributes {dialect.a = "a\22quoted\22string", dialect.b = 4.000000e+00 : f64, dialect.c = tensor<*xf32>}
attributes {dialect.a = "a\"quoted\"string", dialect.b = 4.0, dialect.c = tensor<*xf32>} {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb0:
Add function attributes for ExtFunction, CFGFunction and MLFunction. PiperOrigin-RevId: 213540509
2018-09-19 07:36:26 +08:00
return
}
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @funcattrwithblock
func @funcattrwithblock() -> ()
Add function attributes for ExtFunction, CFGFunction and MLFunction. PiperOrigin-RevId: 213540509
2018-09-19 07:36:26 +08:00
attributes {} {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb0:
Add function attributes for ExtFunction, CFGFunction and MLFunction. PiperOrigin-RevId: 213540509
2018-09-19 07:36:26 +08:00
return
}
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-label func @funcsimplemap
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
#map_simple0 = affine_map<()[] -> (10)>
#map_simple1 = affine_map<()[s0] -> (s0)>
#map_non_simple0 = affine_map<(d0)[] -> (d0)>
#map_non_simple1 = affine_map<(d0)[s0] -> (d0 + s0)>
#map_non_simple2 = affine_map<()[s0, s1] -> (s0 + s1)>
#map_non_simple3 = affine_map<()[s0] -> (s0 + 3)>
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
func @funcsimplemap(%arg0: index, %arg1: index) -> () {
NFC: Rename the 'for' operation in the AffineOps dialect to 'affine.for' and set the namespace of the AffineOps dialect to 'affine'. PiperOrigin-RevId: 240165792
2019-03-26 01:14:34 +08:00
affine.for %i0 = 0 to #map_simple0()[] {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: affine.for %{{.*}} = 0 to 10 {
NFC: Rename the 'for' operation in the AffineOps dialect to 'affine.for' and set the namespace of the AffineOps dialect to 'affine'. PiperOrigin-RevId: 240165792
2019-03-26 01:14:34 +08:00
affine.for %i1 = 0 to #map_simple1()[%arg1] {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: affine.for %{{.*}} = 0 to %{{.*}} {
NFC: Rename the 'for' operation in the AffineOps dialect to 'affine.for' and set the namespace of the AffineOps dialect to 'affine'. PiperOrigin-RevId: 240165792
2019-03-26 01:14:34 +08:00
affine.for %i2 = 0 to #map_non_simple0(%i0)[] {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: affine.for %{{.*}} = 0 to #map{{[a-z_0-9]*}}(%{{.*}}) {
NFC: Rename the 'for' operation in the AffineOps dialect to 'affine.for' and set the namespace of the AffineOps dialect to 'affine'. PiperOrigin-RevId: 240165792
2019-03-26 01:14:34 +08:00
affine.for %i3 = 0 to #map_non_simple1(%i0)[%arg1] {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: affine.for %{{.*}} = 0 to #map{{[a-z_0-9]*}}(%{{.*}})[%{{.*}}] {
NFC: Rename the 'for' operation in the AffineOps dialect to 'affine.for' and set the namespace of the AffineOps dialect to 'affine'. PiperOrigin-RevId: 240165792
2019-03-26 01:14:34 +08:00
affine.for %i4 = 0 to #map_non_simple2()[%arg1, %arg0] {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: affine.for %{{.*}} = 0 to #map{{[a-z_0-9]*}}()[%{{.*}}, %{{.*}}] {
NFC: Rename the 'for' operation in the AffineOps dialect to 'affine.for' and set the namespace of the AffineOps dialect to 'affine'. PiperOrigin-RevId: 240165792
2019-03-26 01:14:34 +08:00
affine.for %i5 = 0 to #map_non_simple3()[%arg0] {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: affine.for %{{.*}} = 0 to #map{{[a-z_0-9]*}}()[%{{.*}}] {
[MLIR] Fix AsmPrinter for short-hand bound notation This CL retricts shorthand notation printing to only the bounds that can be roundtripped unambiguously; i.e.: 1. ()[]->(%some_cst) ()[] 2. ()[s0]->(s0) ()[%some_symbol] Upon inspection it turns out that the constant case was lossy so this CL also updates it. Note however that fixing this issue exhibits a potential issues in unroll.mlir. L488 exhibits a map ()[s0] -> (1)()[%arg0] which could be simplified down to ()[]->(1)()[]. This does not seem like a bug but maybe an undesired complexity in the maps generated by unrolling. bondhugula@, care to take a look? PiperOrigin-RevId: 214531410
2018-09-26 08:15:54 +08:00
%c42_i32 = constant 42 : i32
}
}
}
}
[MLIR] Fix AsmPrinter.cpp for single ssa-id AffineMap The AsmPrinter wrongly assumes that all single ssa-id AffineMap are the identity map for the purpose of printing. This CL adds the missing level of indirection as well as a test. This bug was originally shaken off by the experimental TC->MLIR path. Before this CL, the test would print: ``` mlfunc @mlfuncsimplemap(%arg0 : affineint, %arg1 : affineint, %arg2 : affineint) { for %i0 = 0 to %arg0 { for %i1 = 0 to %i0 { ~~~ should be %arg1 %c42_i32 = constant 42 : i32 } } return } ``` PiperOrigin-RevId: 214120817
2018-09-23 01:35:44 +08:00
}
}
return
}
Add support to constant splat vector/tensor attribute. This attribute represents a reference to a splat vector or tensor, where all the elements have the same value. The syntax of the attribute is: `splat<` (tensor-type | vector-type)`,` attribute-value `>` PiperOrigin-RevId: 216537997
2018-10-10 23:57:51 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @splattensorattr
func @splattensorattr() -> () {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb0:
Print boolean values in ElementsAttr as "true"/"false" We already parse boolean "true"/"false" as ElementsAttr elements. This CL makes it round-trippable that we are printing the same way. PiperOrigin-RevId: 258784962
2019-07-19 00:24:41 +08:00
// CHECK: "splatBoolTensor"() {bar = dense<false> : tensor<i1>} : () -> ()
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
"splatBoolTensor"(){bar = dense<false> : tensor<i1>} : () -> ()
Add support for parsing true/false inside of a splat tensor literal. PiperOrigin-RevId: 239052061
2019-03-19 04:42:55 +08:00
[mlir] Update several usages of IntegerType to properly handled unsignedness. Summary: For example, DenseElementsAttr currently does not properly round-trip unsigned integer values. Differential Revision: https://reviews.llvm.org/D75374
2020-03-03 01:18:45 +08:00
// CHECK: "splatUIntTensor"() {bar = dense<222> : tensor<2x1x4xui8>} : () -> ()
"splatUIntTensor"(){bar = dense<222> : tensor<2x1x4xui8>} : () -> ()
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "splatIntTensor"() {bar = dense<5> : tensor<2x1x4xi32>} : () -> ()
"splatIntTensor"(){bar = dense<5> : tensor<2x1x4xi32>} : () -> ()
Add support for parsing true/false inside of a splat tensor literal. PiperOrigin-RevId: 239052061
2019-03-19 04:42:55 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "splatFloatTensor"() {bar = dense<-5.000000e+00> : tensor<2x1x4xf32>} : () -> ()
"splatFloatTensor"(){bar = dense<-5.0> : tensor<2x1x4xf32>} : () -> ()
Add support for parsing true/false inside of a splat tensor literal. PiperOrigin-RevId: 239052061
2019-03-19 04:42:55 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "splatIntVector"() {bar = dense<5> : vector<2x1x4xi64>} : () -> ()
"splatIntVector"(){bar = dense<5> : vector<2x1x4xi64>} : () -> ()
Add support for parsing true/false inside of a splat tensor literal. PiperOrigin-RevId: 239052061
2019-03-19 04:42:55 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "splatFloatVector"() {bar = dense<-5.000000e+00> : vector<2x1x4xf16>} : () -> ()
"splatFloatVector"(){bar = dense<-5.0> : vector<2x1x4xf16>} : () -> ()
Support 0-d tensor type attributes This CL fixes the parser and printer to support the 0-d tensor type attributes. -- PiperOrigin-RevId: 241345329
2019-04-02 01:01:47 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "splatIntScalar"() {bar = dense<5> : tensor<i9>} : () -> ()
"splatIntScalar"() {bar = dense<5> : tensor<i9>} : () -> ()
// CHECK: "splatFloatScalar"() {bar = dense<-5.000000e+00> : tensor<f16>} : () -> ()
"splatFloatScalar"() {bar = dense<-5.0> : tensor<f16>} : () -> ()
Add support to constant splat vector/tensor attribute. This attribute represents a reference to a splat vector or tensor, where all the elements have the same value. The syntax of the attribute is: `splat<` (tensor-type | vector-type)`,` attribute-value `>` PiperOrigin-RevId: 216537997
2018-10-10 23:57:51 +08:00
return
}
Add support to constant dense vector/tensor attribute. The syntax of dense vecor/tensor attribute value is `dense<` (tensor-type | vector-type)`,` attribute-list`>` and attribute-list ::= `[` attribute-list (`, ` attribute-list)* `]`. The construction of the dense vector/tensor attribute takes a vector/tensor type and a character array as arguments. The size of the input array should be larger than the size specified by the type argument. It also assumes the elements of the vector or tensor have been trunked to the data type sizes in the input character array, so it extends the trunked data to 64 bits when it is retrieved. PiperOrigin-RevId: 217762811
2018-10-19 04:54:44 +08:00
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @densetensorattr
func @densetensorattr() -> () {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb0:
Add support to constant dense vector/tensor attribute. The syntax of dense vecor/tensor attribute value is `dense<` (tensor-type | vector-type)`,` attribute-list`>` and attribute-list ::= `[` attribute-list (`, ` attribute-list)* `]`. The construction of the dense vector/tensor attribute takes a vector/tensor type and a character array as arguments. The size of the input array should be larger than the size specified by the type argument. It also assumes the elements of the vector or tensor have been trunked to the data type sizes in the input character array, so it extends the trunked data to 64 bits when it is retrieved. PiperOrigin-RevId: 217762811
2018-10-19 04:54:44 +08:00
// NOTE: The {{\[\[}} syntax is because "[[" confuses FileCheck.
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "fooi3"() {bar = dense<{{\[\[\[}}1, -2, 1, 2]], {{\[\[}}0, 2, -1, 2]]]> : tensor<2x1x4xi3>} : () -> ()
"fooi3"(){bar = dense<[[[1, -2, 1, 2]], [[0, 2, -1, 2]]]> : tensor<2x1x4xi3>} : () -> ()
// CHECK: "fooi6"() {bar = dense<{{\[\[\[}}5, -6, 1, 2]], {{\[\[}}7, 8, 3, 4]]]> : tensor<2x1x4xi6>} : () -> ()
"fooi6"(){bar = dense<[[[5, -6, 1, 2]], [[7, 8, 3, 4]]]> : tensor<2x1x4xi6>} : () -> ()
// CHECK: "fooi8"() {bar = dense<5> : tensor<1x1x1xi8>} : () -> ()
"fooi8"(){bar = dense<[[[5]]]> : tensor<1x1x1xi8>} : () -> ()
// CHECK: "fooi13"() {bar = dense<{{\[\[\[}}1, -2, 1, 2]], {{\[\[}}0, 2, -1, 2]]]> : tensor<2x1x4xi13>} : () -> ()
"fooi13"(){bar = dense<[[[1, -2, 1, 2]], [[0, 2, -1, 2]]]> : tensor<2x1x4xi13>} : () -> ()
// CHECK: "fooi16"() {bar = dense<-5> : tensor<1x1x1xi16>} : () -> ()
"fooi16"(){bar = dense<[[[-5]]]> : tensor<1x1x1xi16>} : () -> ()
// CHECK: "fooi23"() {bar = dense<{{\[\[\[}}1, -2, 1, 2]], {{\[\[}}0, 2, -1, 2]]]> : tensor<2x1x4xi23>} : () -> ()
"fooi23"(){bar = dense<[[[1, -2, 1, 2]], [[0, 2, -1, 2]]]> : tensor<2x1x4xi23>} : () -> ()
// CHECK: "fooi32"() {bar = dense<5> : tensor<1x1x1xi32>} : () -> ()
"fooi32"(){bar = dense<[[[5]]]> : tensor<1x1x1xi32>} : () -> ()
// CHECK: "fooi33"() {bar = dense<{{\[\[\[}}1, -2, 1, 2]], {{\[\[}}0, 2, -1, 2]]]> : tensor<2x1x4xi33>} : () -> ()
"fooi33"(){bar = dense<[[[1, -2, 1, 2]], [[0, 2, -1, 2]]]> : tensor<2x1x4xi33>} : () -> ()
// CHECK: "fooi43"() {bar = dense<{{\[\[\[}}1, -2, 1, 2]], {{\[\[}}0, 2, -1, 2]]]> : tensor<2x1x4xi43>} : () -> ()
"fooi43"(){bar = dense<[[[1, -2, 1, 2]], [[0, 2, -1, 2]]]> : tensor<2x1x4xi43>} : () -> ()
// CHECK: "fooi53"() {bar = dense<{{\[\[\[}}1, -2, 1, 2]], {{\[\[}}0, 2, -1, 2]]]> : tensor<2x1x4xi53>} : () -> ()
"fooi53"(){bar = dense<[[[1, -2, 1, 2]], [[0, 2, -1, 2]]]> : tensor<2x1x4xi53>} : () -> ()
// CHECK: "fooi64"() {bar = dense<{{\[\[\[}}1, -2, 1, 2]], {{\[\[}}0, 3, -1, 2]]]> : tensor<2x1x4xi64>} : () -> ()
"fooi64"(){bar = dense<[[[1, -2, 1, 2]], [[0, 3, -1, 2]]]> : tensor<2x1x4xi64>} : () -> ()
// CHECK: "fooi64"() {bar = dense<-5> : tensor<1x1x1xi64>} : () -> ()
"fooi64"(){bar = dense<[[[-5]]]> : tensor<1x1x1xi64>} : () -> ()
// CHECK: "fooi67"() {bar = dense<{{\[\[\[}}-5, 4, 6, 2]]]> : vector<1x1x4xi67>} : () -> ()
"fooi67"(){bar = dense<[[[-5, 4, 6, 2]]]> : vector<1x1x4xi67>} : () -> ()
[mlir] Print 0 element DenseElementsAttr as dense<> to fix parser bugs with expected shape. Depending on where the 0 dimension is within the shape, the parser will currently reject .mlir generated by the printer. Differential Revision: https://reviews.llvm.org/D83445
2020-07-09 08:44:27 +08:00
// CHECK: "foo2"() {bar = dense<> : tensor<0xi32>} : () -> ()
"foo2"(){bar = dense<> : tensor<0xi32>} : () -> ()
// CHECK: "foo2"() {bar = dense<> : tensor<1x0xi32>} : () -> ()
"foo2"(){bar = dense<> : tensor<1x0xi32>} : () -> ()
// CHECK: dense<> : tensor<0x512x512xi32>
"foo2"(){bar = dense<> : tensor<0x512x512xi32>} : () -> ()
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo3"() {bar = dense<{{\[\[\[}}5, -6, 1, 2]], {{\[\[}}7, 8, 3, 4]]]> : tensor<2x1x4xi32>} : () -> ()
"foo3"(){bar = dense<[[[5, -6, 1, 2]], [[7, 8, 3, 4]]]> : tensor<2x1x4xi32>} : () -> ()
// CHECK: "float1"() {bar = dense<5.000000e+00> : tensor<1x1x1xf32>} : () -> ()
"float1"(){bar = dense<[[[5.0]]]> : tensor<1x1x1xf32>} : () -> ()
[mlir] Print 0 element DenseElementsAttr as dense<> to fix parser bugs with expected shape. Depending on where the 0 dimension is within the shape, the parser will currently reject .mlir generated by the printer. Differential Revision: https://reviews.llvm.org/D83445
2020-07-09 08:44:27 +08:00
// CHECK: "float2"() {bar = dense<> : tensor<0xf32>} : () -> ()
"float2"(){bar = dense<> : tensor<0xf32>} : () -> ()
// CHECK: "float2"() {bar = dense<> : tensor<1x0xf32>} : () -> ()
"float2"(){bar = dense<> : tensor<1x0xf32>} : () -> ()
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "bfloat16"() {bar = dense<{{\[\[\[}}-5.000000e+00, 6.000000e+00, 1.000000e+00, 2.000000e+00]], {{\[\[}}7.000000e+00, -8.000000e+00, 3.000000e+00, 4.000000e+00]]]> : tensor<2x1x4xbf16>} : () -> ()
"bfloat16"(){bar = dense<[[[-5.0, 6.0, 1.0, 2.0]], [[7.0, -8.0, 3.0, 4.0]]]> : tensor<2x1x4xbf16>} : () -> ()
// CHECK: "float16"() {bar = dense<{{\[\[\[}}-5.000000e+00, 6.000000e+00, 1.000000e+00, 2.000000e+00]], {{\[\[}}7.000000e+00, -8.000000e+00, 3.000000e+00, 4.000000e+00]]]> : tensor<2x1x4xf16>} : () -> ()
"float16"(){bar = dense<[[[-5.0, 6.0, 1.0, 2.0]], [[7.0, -8.0, 3.0, 4.0]]]> : tensor<2x1x4xf16>} : () -> ()
// CHECK: "float32"() {bar = dense<{{\[\[\[}}-5.000000e+00, 6.000000e+00, 1.000000e+00, 2.000000e+00]], {{\[\[}}7.000000e+00, -8.000000e+00, 3.000000e+00, 4.000000e+00]]]> : tensor<2x1x4xf32>} : () -> ()
"float32"(){bar = dense<[[[-5.0, 6.0, 1.0, 2.0]], [[7.0, -8.0, 3.0, 4.0]]]> : tensor<2x1x4xf32>} : () -> ()
// CHECK: "float64"() {bar = dense<{{\[\[\[}}-5.000000e+00, 6.000000e+00, 1.000000e+00, 2.000000e+00]], {{\[\[}}7.000000e+00, -8.000000e+00, 3.000000e+00, 4.000000e+00]]]> : tensor<2x1x4xf64>} : () -> ()
"float64"(){bar = dense<[[[-5.0, 6.0, 1.0, 2.0]], [[7.0, -8.0, 3.0, 4.0]]]> : tensor<2x1x4xf64>} : () -> ()
// CHECK: "intscalar"() {bar = dense<1> : tensor<i32>} : () -> ()
"intscalar"(){bar = dense<1> : tensor<i32>} : () -> ()
// CHECK: "floatscalar"() {bar = dense<5.000000e+00> : tensor<f32>} : () -> ()
"floatscalar"(){bar = dense<5.0> : tensor<f32>} : () -> ()
Add support for IndexType inside DenseIntElementsAttr. This also fixes issues discovered in the parsing/printing path.
2020-04-24 06:47:31 +08:00
// CHECK: "index"() {bar = dense<1> : tensor<index>} : () -> ()
"index"(){bar = dense<1> : tensor<index>} : () -> ()
// CHECK: "index"() {bar = dense<[1, 2]> : tensor<2xindex>} : () -> ()
"index"(){bar = dense<[1, 2]> : tensor<2xindex>} : () -> ()
[mlir][DenseElementsAttr] Add support for opaque APFloat/APInt complex values. This revision allows for creating DenseElementsAttrs and accessing elements using std::complex<APInt>/std::complex<APFloat>. This allows for opaquely accessing and transforming complex values. This is used by the printer/parser to provide pretty printing for complex values. The form for complex values matches that of std::complex, i.e.: ``` // `(` element `,` element `)` dense<(10,10)> : tensor<complex<i64>> ``` Differential Revision: https://reviews.llvm.org/D79296
2020-05-06 03:39:22 +08:00
// CHECK: dense<(1,1)> : tensor<complex<i64>>
"complex_attr"(){bar = dense<(1,1)> : tensor<complex<i64>>} : () -> ()
// CHECK: dense<[(1,1), (2,2)]> : tensor<2xcomplex<i64>>
"complex_attr"(){bar = dense<[(1,1), (2,2)]> : tensor<2xcomplex<i64>>} : () -> ()
// CHECK: dense<(1.000000e+00,0.000000e+00)> : tensor<complex<f32>>
"complex_attr"(){bar = dense<(1.000000e+00,0.000000e+00)> : tensor<complex<f32>>} : () -> ()
// CHECK: dense<[(1.000000e+00,0.000000e+00), (2.000000e+00,2.000000e+00)]> : tensor<2xcomplex<f32>>
"complex_attr"(){bar = dense<[(1.000000e+00,0.000000e+00), (2.000000e+00,2.000000e+00)]> : tensor<2xcomplex<f32>>} : () -> ()
Add support to constant dense vector/tensor attribute. The syntax of dense vecor/tensor attribute value is `dense<` (tensor-type | vector-type)`,` attribute-list`>` and attribute-list ::= `[` attribute-list (`, ` attribute-list)* `]`. The construction of the dense vector/tensor attribute takes a vector/tensor type and a character array as arguments. The size of the input array should be larger than the size specified by the type argument. It also assumes the elements of the vector or tensor have been trunked to the data type sizes in the input character array, so it extends the trunked data to 64 bits when it is retrieved. PiperOrigin-RevId: 217762811
2018-10-19 04:54:44 +08:00
return
}
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @densevectorattr
func @densevectorattr() -> () {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb0:
Add support to constant dense vector/tensor attribute. The syntax of dense vecor/tensor attribute value is `dense<` (tensor-type | vector-type)`,` attribute-list`>` and attribute-list ::= `[` attribute-list (`, ` attribute-list)* `]`. The construction of the dense vector/tensor attribute takes a vector/tensor type and a character array as arguments. The size of the input array should be larger than the size specified by the type argument. It also assumes the elements of the vector or tensor have been trunked to the data type sizes in the input character array, so it extends the trunked data to 64 bits when it is retrieved. PiperOrigin-RevId: 217762811
2018-10-19 04:54:44 +08:00
// NOTE: The {{\[\[}} syntax is because "[[" confuses FileCheck.
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "fooi8"() {bar = dense<5> : vector<1x1x1xi8>} : () -> ()
"fooi8"(){bar = dense<[[[5]]]> : vector<1x1x1xi8>} : () -> ()
// CHECK: "fooi16"() {bar = dense<-5> : vector<1x1x1xi16>} : () -> ()
"fooi16"(){bar = dense<[[[-5]]]> : vector<1x1x1xi16>} : () -> ()
// CHECK: "foo32"() {bar = dense<5> : vector<1x1x1xi32>} : () -> ()
"foo32"(){bar = dense<[[[5]]]> : vector<1x1x1xi32>} : () -> ()
// CHECK: "fooi64"() {bar = dense<-5> : vector<1x1x1xi64>} : () -> ()
"fooi64"(){bar = dense<[[[-5]]]> : vector<1x1x1xi64>} : () -> ()
// CHECK: "foo3"() {bar = dense<{{\[\[\[}}5, -6, 1, 2]], {{\[\[}}7, 8, 3, 4]]]> : vector<2x1x4xi32>} : () -> ()
"foo3"(){bar = dense<[[[5, -6, 1, 2]], [[7, 8, 3, 4]]]> : vector<2x1x4xi32>} : () -> ()
// CHECK: "float1"() {bar = dense<5.000000e+00> : vector<1x1x1xf32>} : () -> ()
"float1"(){bar = dense<[[[5.0]]]> : vector<1x1x1xf32>} : () -> ()
// CHECK: "bfloat16"() {bar = dense<{{\[\[\[}}-5.000000e+00, 6.000000e+00, 1.000000e+00, 2.000000e+00]], {{\[\[}}7.000000e+00, -8.000000e+00, 3.000000e+00, 4.000000e+00]]]> : vector<2x1x4xbf16>} : () -> ()
"bfloat16"(){bar = dense<[[[-5.0, 6.0, 1.0, 2.0]], [[7.0, -8.0, 3.0, 4.0]]]> : vector<2x1x4xbf16>} : () -> ()
// CHECK: "float16"() {bar = dense<{{\[\[\[}}-5.000000e+00, 6.000000e+00, 1.000000e+00, 2.000000e+00]], {{\[\[}}7.000000e+00, -8.000000e+00, 3.000000e+00, 4.000000e+00]]]> : vector<2x1x4xf16>} : () -> ()
"float16"(){bar = dense<[[[-5.0, 6.0, 1.0, 2.0]], [[7.0, -8.0, 3.0, 4.0]]]> : vector<2x1x4xf16>} : () -> ()
// CHECK: "float32"() {bar = dense<{{\[\[\[}}-5.000000e+00, 6.000000e+00, 1.000000e+00, 2.000000e+00]], {{\[\[}}7.000000e+00, -8.000000e+00, 3.000000e+00, 4.000000e+00]]]> : vector<2x1x4xf32>} : () -> ()
"float32"(){bar = dense<[[[-5.0, 6.0, 1.0, 2.0]], [[7.0, -8.0, 3.0, 4.0]]]> : vector<2x1x4xf32>} : () -> ()
// CHECK: "float64"() {bar = dense<{{\[\[\[}}-5.000000e+00, 6.000000e+00, 1.000000e+00, 2.000000e+00]], {{\[\[}}7.000000e+00, -8.000000e+00, 3.000000e+00, 4.000000e+00]]]> : vector<2x1x4xf64>} : () -> ()
"float64"(){bar = dense<[[[-5.0, 6.0, 1.0, 2.0]], [[7.0, -8.0, 3.0, 4.0]]]> : vector<2x1x4xf64>} : () -> ()
Add support to constant dense vector/tensor attribute. The syntax of dense vecor/tensor attribute value is `dense<` (tensor-type | vector-type)`,` attribute-list`>` and attribute-list ::= `[` attribute-list (`, ` attribute-list)* `]`. The construction of the dense vector/tensor attribute takes a vector/tensor type and a character array as arguments. The size of the input array should be larger than the size specified by the type argument. It also assumes the elements of the vector or tensor have been trunked to the data type sizes in the input character array, so it extends the trunked data to 64 bits when it is retrieved. PiperOrigin-RevId: 217762811
2018-10-19 04:54:44 +08:00
return
Add support to constant sparse tensor / vector attribute The SparseElementsAttr uses (COO) Coordinate List encoding to represents a sparse tensor / vector. Specifically, the coordinates and values are stored as two dense elements attributes. The first dense elements attribute is a 2-D attribute with shape [N, ndims], which contains the indices of the elements with nonzero values in the constant vector/tensor. The second elements attribute is a 1-D attribute list with shape [N], which supplies the values for each element in the first elements attribute. ndims is the rank of the vector/tensor and N is the total nonzero elements. The syntax is: `sparse<` (tensor-type | vector-type)`, ` indices-attribute-list, values-attribute-list `>` Example: a sparse tensor sparse<vector<3x4xi32>, [[0, 0], [1, 2]], [1, 2]> represents the dense tensor [[1, 0, 0, 0] [0, 0, 2, 0] [0, 0, 0, 0]] PiperOrigin-RevId: 217764319
2018-10-19 05:02:20 +08:00
}
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @sparsetensorattr
func @sparsetensorattr() -> () {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb0:
Add support to constant sparse tensor / vector attribute The SparseElementsAttr uses (COO) Coordinate List encoding to represents a sparse tensor / vector. Specifically, the coordinates and values are stored as two dense elements attributes. The first dense elements attribute is a 2-D attribute with shape [N, ndims], which contains the indices of the elements with nonzero values in the constant vector/tensor. The second elements attribute is a 1-D attribute list with shape [N], which supplies the values for each element in the first elements attribute. ndims is the rank of the vector/tensor and N is the total nonzero elements. The syntax is: `sparse<` (tensor-type | vector-type)`, ` indices-attribute-list, values-attribute-list `>` Example: a sparse tensor sparse<vector<3x4xi32>, [[0, 0], [1, 2]], [1, 2]> represents the dense tensor [[1, 0, 0, 0] [0, 0, 2, 0] [0, 0, 0, 0]] PiperOrigin-RevId: 217764319
2018-10-19 05:02:20 +08:00
// NOTE: The {{\[\[}} syntax is because "[[" confuses FileCheck.
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "fooi8"() {bar = sparse<0, -2> : tensor<1x1x1xi8>} : () -> ()
"fooi8"(){bar = sparse<0, -2> : tensor<1x1x1xi8>} : () -> ()
// CHECK: "fooi16"() {bar = sparse<{{\[\[}}1, 1, 0], {{\[}}0, 1, 0], {{\[}}0, 0, 1]], {{\[}}2, -1, 5]> : tensor<2x2x2xi16>} : () -> ()
"fooi16"(){bar = sparse<[[1, 1, 0], [0, 1, 0], [0, 0, 1]], [2, -1, 5]> : tensor<2x2x2xi16>} : () -> ()
[mlir] Print 0 element DenseElementsAttr as dense<> to fix parser bugs with expected shape. Depending on where the 0 dimension is within the shape, the parser will currently reject .mlir generated by the printer. Differential Revision: https://reviews.llvm.org/D83445
2020-07-09 08:44:27 +08:00
// CHECK: "fooi32"() {bar = sparse<> : tensor<1x1xi32>} : () -> ()
"fooi32"(){bar = sparse<> : tensor<1x1xi32>} : () -> ()
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "fooi64"() {bar = sparse<0, -1> : tensor<1xi64>} : () -> ()
"fooi64"(){bar = sparse<[[0]], [-1]> : tensor<1xi64>} : () -> ()
[mlir] Print 0 element DenseElementsAttr as dense<> to fix parser bugs with expected shape. Depending on where the 0 dimension is within the shape, the parser will currently reject .mlir generated by the printer. Differential Revision: https://reviews.llvm.org/D83445
2020-07-09 08:44:27 +08:00
// CHECK: "foo2"() {bar = sparse<> : tensor<0xi32>} : () -> ()
"foo2"(){bar = sparse<> : tensor<0xi32>} : () -> ()
// CHECK: "foo3"() {bar = sparse<> : tensor<i32>} : () -> ()
"foo3"(){bar = sparse<> : tensor<i32>} : () -> ()
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foof16"() {bar = sparse<0, -2.000000e+00> : tensor<1x1x1xf16>} : () -> ()
"foof16"(){bar = sparse<0, -2.0> : tensor<1x1x1xf16>} : () -> ()
// CHECK: "foobf16"() {bar = sparse<{{\[\[}}1, 1, 0], {{\[}}0, 1, 0], {{\[}}0, 0, 1]], {{\[}}2.000000e+00, -1.000000e+00, 5.000000e+00]> : tensor<2x2x2xbf16>} : () -> ()
"foobf16"(){bar = sparse<[[1, 1, 0], [0, 1, 0], [0, 0, 1]], [2.0, -1.0, 5.0]> : tensor<2x2x2xbf16>} : () -> ()
[mlir] Print 0 element DenseElementsAttr as dense<> to fix parser bugs with expected shape. Depending on where the 0 dimension is within the shape, the parser will currently reject .mlir generated by the printer. Differential Revision: https://reviews.llvm.org/D83445
2020-07-09 08:44:27 +08:00
// CHECK: "foof32"() {bar = sparse<> : tensor<1x0x1xf32>} : () -> ()
"foof32"(){bar = sparse<> : tensor<1x0x1xf32>} : () -> ()
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foof64"() {bar = sparse<0, -1.000000e+00> : tensor<1xf64>} : () -> ()
"foof64"(){bar = sparse<[[0]], [-1.0]> : tensor<1xf64>} : () -> ()
[mlir] Print 0 element DenseElementsAttr as dense<> to fix parser bugs with expected shape. Depending on where the 0 dimension is within the shape, the parser will currently reject .mlir generated by the printer. Differential Revision: https://reviews.llvm.org/D83445
2020-07-09 08:44:27 +08:00
// CHECK: "foof320"() {bar = sparse<> : tensor<0xf32>} : () -> ()
"foof320"(){bar = sparse<> : tensor<0xf32>} : () -> ()
// CHECK: "foof321"() {bar = sparse<> : tensor<f32>} : () -> ()
"foof321"(){bar = sparse<> : tensor<f32>} : () -> ()
[mlir] Add support for sparse DenseStringElements. Summary: Added support for sparse strings elements. This is a follow up from the original DenseStringElements. Differential Revision: https://reviews.llvm.org/D78844
2020-04-25 16:17:09 +08:00
// CHECK: "foostr"() {bar = sparse<0, "foo"> : tensor<1x1x1x!unknown<"">>} : () -> ()
"foostr"(){bar = sparse<0, "foo"> : tensor<1x1x1x!unknown<"">>} : () -> ()
// CHECK: "foostr"() {bar = sparse<{{\[\[}}1, 1, 0], {{\[}}0, 1, 0], {{\[}}0, 0, 1]], {{\[}}"a", "b", "c"]> : tensor<2x2x2x!unknown<"">>} : () -> ()
"foostr"(){bar = sparse<[[1, 1, 0], [0, 1, 0], [0, 0, 1]], ["a", "b", "c"]> : tensor<2x2x2x!unknown<"">>} : () -> ()
Add support to constant sparse tensor / vector attribute The SparseElementsAttr uses (COO) Coordinate List encoding to represents a sparse tensor / vector. Specifically, the coordinates and values are stored as two dense elements attributes. The first dense elements attribute is a 2-D attribute with shape [N, ndims], which contains the indices of the elements with nonzero values in the constant vector/tensor. The second elements attribute is a 1-D attribute list with shape [N], which supplies the values for each element in the first elements attribute. ndims is the rank of the vector/tensor and N is the total nonzero elements. The syntax is: `sparse<` (tensor-type | vector-type)`, ` indices-attribute-list, values-attribute-list `>` Example: a sparse tensor sparse<vector<3x4xi32>, [[0, 0], [1, 2]], [1, 2]> represents the dense tensor [[1, 0, 0, 0] [0, 0, 2, 0] [0, 0, 0, 0]] PiperOrigin-RevId: 217764319
2018-10-19 05:02:20 +08:00
return
}
Eliminate extfunc/cfgfunc/mlfunc as a concept, and just use 'func' instead. The entire compiler now looks at structural properties of the function (e.g. does it have one block, does it contain an if/for stmt, etc) so the only thing holding up this difference is round tripping through the parser/printer syntax. Removing this shrinks the compile by ~140LOC. This is step 31/n towards merging instructions and statements. The last step is updating the docs, which I will do as a separate patch in order to split it from this mostly mechanical patch. PiperOrigin-RevId: 227540453
2019-01-03 02:20:00 +08:00
// CHECK-LABEL: func @sparsevectorattr
func @sparsevectorattr() -> () {
Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR syntax. PiperOrigin-RevId: 227234174
2018-12-30 03:32:37 +08:00
^bb0:
Add support to constant sparse tensor / vector attribute The SparseElementsAttr uses (COO) Coordinate List encoding to represents a sparse tensor / vector. Specifically, the coordinates and values are stored as two dense elements attributes. The first dense elements attribute is a 2-D attribute with shape [N, ndims], which contains the indices of the elements with nonzero values in the constant vector/tensor. The second elements attribute is a 1-D attribute list with shape [N], which supplies the values for each element in the first elements attribute. ndims is the rank of the vector/tensor and N is the total nonzero elements. The syntax is: `sparse<` (tensor-type | vector-type)`, ` indices-attribute-list, values-attribute-list `>` Example: a sparse tensor sparse<vector<3x4xi32>, [[0, 0], [1, 2]], [1, 2]> represents the dense tensor [[1, 0, 0, 0] [0, 0, 2, 0] [0, 0, 0, 0]] PiperOrigin-RevId: 217764319
2018-10-19 05:02:20 +08:00
// NOTE: The {{\[\[}} syntax is because "[[" confuses FileCheck.
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "fooi8"() {bar = sparse<0, -2> : vector<1x1x1xi8>} : () -> ()
"fooi8"(){bar = sparse<0, -2> : vector<1x1x1xi8>} : () -> ()
// CHECK: "fooi16"() {bar = sparse<{{\[\[}}1, 1, 0], {{\[}}0, 1, 0], {{\[}}0, 0, 1]], {{\[}}2, -1, 5]> : vector<2x2x2xi16>} : () -> ()
"fooi16"(){bar = sparse<[[1, 1, 0], [0, 1, 0], [0, 0, 1]], [2, -1, 5]> : vector<2x2x2xi16>} : () -> ()
[mlir] Print 0 element DenseElementsAttr as dense<> to fix parser bugs with expected shape. Depending on where the 0 dimension is within the shape, the parser will currently reject .mlir generated by the printer. Differential Revision: https://reviews.llvm.org/D83445
2020-07-09 08:44:27 +08:00
// CHECK: "fooi32"() {bar = sparse<> : vector<1x1xi32>} : () -> ()
"fooi32"(){bar = sparse<> : vector<1x1xi32>} : () -> ()
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "fooi64"() {bar = sparse<0, -1> : vector<1xi64>} : () -> ()
"fooi64"(){bar = sparse<[[0]], [-1]> : vector<1xi64>} : () -> ()
// CHECK: "foof16"() {bar = sparse<0, -2.000000e+00> : vector<1x1x1xf16>} : () -> ()
"foof16"(){bar = sparse<0, -2.0> : vector<1x1x1xf16>} : () -> ()
// CHECK: "foobf16"() {bar = sparse<{{\[\[}}1, 1, 0], {{\[}}0, 1, 0], {{\[}}0, 0, 1]], {{\[}}2.000000e+00, -1.000000e+00, 5.000000e+00]> : vector<2x2x2xbf16>} : () -> ()
"foobf16"(){bar = sparse<[[1, 1, 0], [0, 1, 0], [0, 0, 1]], [2.0, -1.0, 5.0]> : vector<2x2x2xbf16>} : () -> ()
// CHECK: "foof64"() {bar = sparse<0, -1.000000e+00> : vector<1xf64>} : () -> ()
"foof64"(){bar = sparse<0, [-1.0]> : vector<1xf64>} : () -> ()
Add support to constant sparse tensor / vector attribute The SparseElementsAttr uses (COO) Coordinate List encoding to represents a sparse tensor / vector. Specifically, the coordinates and values are stored as two dense elements attributes. The first dense elements attribute is a 2-D attribute with shape [N, ndims], which contains the indices of the elements with nonzero values in the constant vector/tensor. The second elements attribute is a 1-D attribute list with shape [N], which supplies the values for each element in the first elements attribute. ndims is the rank of the vector/tensor and N is the total nonzero elements. The syntax is: `sparse<` (tensor-type | vector-type)`, ` indices-attribute-list, values-attribute-list `>` Example: a sparse tensor sparse<vector<3x4xi32>, [[0, 0], [1, 2]], [1, 2]> represents the dense tensor [[1, 0, 0, 0] [0, 0, 2, 0] [0, 0, 0, 0]] PiperOrigin-RevId: 217764319
2018-10-19 05:02:20 +08:00
return
Change sigil for integer set: @@ -> # PiperOrigin-RevId: 218786684
2018-10-26 09:33:42 +08:00
}
Clean up and improve the parser handling of basic block labels, now that we have a designator. This improves diagnostics and merges handling between CFG and ML functions more. This also eliminates hard coded parser knowledge of terminator keywords, allowing dialects to define their own terminators. PiperOrigin-RevId: 227239398
2018-12-30 05:36:59 +08:00
Add support for types belonging to unknown dialects. This allows for types to be round tripped even if the dialect that defines them is not linked in. These types will be represented by a new "UnknownType" that uniques them based upon the dialect namespace and raw string type data. PiperOrigin-RevId: 228184629
2019-01-08 01:58:34 +08:00
// CHECK-LABEL: func @unknown_dialect_type() -> !bar<""> {
func @unknown_dialect_type() -> !bar<""> {
// Unregistered dialect 'bar'.
// CHECK: "foo"() : () -> !bar<"">
%0 = "foo"() : () -> !bar<"">
Change the asmprinter to use pretty syntax for dialect types when it can, making the IR dumps much nicer. This is part 2/3 of the path to making dialect types more nice. Part 3/3 will slightly generalize the set of characters allowed in pretty types and make it more principled. -- PiperOrigin-RevId: 242249955
2019-04-06 14:56:49 +08:00
// CHECK: "foo"() : () -> !bar.baz
Add support for types belonging to unknown dialects. This allows for types to be round tripped even if the dialect that defines them is not linked in. These types will be represented by a new "UnknownType" that uniques them based upon the dialect namespace and raw string type data. PiperOrigin-RevId: 228184629
2019-01-08 01:58:34 +08:00
%1 = "foo"() : () -> !bar<"baz">
return %0 : !bar<"">
}
Clean up and improve the parser handling of basic block labels, now that we have a designator. This improves diagnostics and merges handling between CFG and ML functions more. This also eliminates hard coded parser knowledge of terminator keywords, allowing dialects to define their own terminators. PiperOrigin-RevId: 227239398
2018-12-30 05:36:59 +08:00
Add parser support for named type aliases. Alias identifiers can be used in the place of the types that they alias, and are defined as: type-alias-def ::= '!' alias-name '=' 'type' type type-alias ::= '!' alias-name Example: !avx.m128 = type vector<4 x f32> ... "foo"(%x) : vector<4 x f32> -> () // becomes: "foo"(%x) : !avx.m128 -> () PiperOrigin-RevId: 228271372
2019-01-08 10:42:04 +08:00
// CHECK-LABEL: func @type_alias() -> i32 {
!i32_type_alias = type i32
func @type_alias() -> !i32_type_alias {
// Return a non-aliased i32 type.
%0 = "foo"() : () -> i32
return %0 : i32
}
Allow operations to hold a blocklist and add support for parsing/printing a block list for verbose printing. PiperOrigin-RevId: 230951462
2019-01-26 04:48:25 +08:00
When parsing, treat an IntegerSet with no constraints as a degenerate true case. Also update the spec to note that affine constraints are optional. PiperOrigin-RevId: 232158673
2019-02-03 13:01:11 +08:00
// CHECK-LABEL: func @no_integer_set_constraints(
func @no_integer_set_constraints() {
Enable FileCheck -enable-var-scope by default in MLIR test This option avoids to accidentally reuse variable across -LABEL match, it can be explicitly opted-in by prefixing the variable name with $ Differential Revision: https://reviews.llvm.org/D81531
2020-06-12 08:34:35 +08:00
// CHECK: affine.if [[$SET_TRUE]]() {
[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types. Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D72429
2020-01-14 05:12:37 +08:00
affine.if affine_set<() : ()> () {
When parsing, treat an IntegerSet with no constraints as a degenerate true case. Also update the spec to note that affine constraints are optional. PiperOrigin-RevId: 232158673
2019-02-03 13:01:11 +08:00
}
return
}
Allow operations to hold a blocklist and add support for parsing/printing a block list for verbose printing. PiperOrigin-RevId: 230951462
2019-01-26 04:48:25 +08:00
// CHECK-LABEL: func @verbose_if(
func @verbose_if(%N: index) {
%c = constant 200 : index
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: affine.if #set{{.*}}(%{{.*}})[%{{.*}}, %{{.*}}] {
Change syntax of regions in the generic form of operations The generic form of operations currently supports optional regions to be located after the operation type. As we are going to add a type to each region in a leading position in the region syntax, similarly to functions, it becomes ambiguous to have regions immediately after the operation type. Put regions between operands the optional list of successors in the generic operation syntax and wrap them in parentheses. The effect on the exisitng IR syntax is minimal since only three operations (`affine.for`, `affine.if` and `gpu.kernel`) currently use regions. -- PiperOrigin-RevId: 246787087
2019-05-06 16:40:13 +08:00
"affine.if"(%c, %N, %c) ({
Allow operations to hold a blocklist and add support for parsing/printing a block list for verbose printing. PiperOrigin-RevId: 230951462
2019-01-26 04:48:25 +08:00
// CHECK-NEXT: "add"
%y = "add"(%c, %N) : (index, index) -> index
Introduce affine terminator Due to legacy reasons (ML/CFG function separation), regions in affine control flow operations require contained blocks not to have terminators. This is inconsistent with the notion of the block and may complicate code motion between regions of affine control operations and other regions. Introduce `affine.terminator`, a special terminator operation that must be used to terminate blocks inside affine operations and transfers the control back to he region enclosing the affine operation. For brevity and readability reasons, allow `affine.for` and `affine.if` to omit the `affine.terminator` in their regions when using custom printing and parsing format. The custom parser injects the `affine.terminator` if it is missing so as to always have it present in constructed operations. Update transformations to account for the presence of terminator. In particular, most code motion transformation between loops should leave the terminator in place, and code motion between loops and non-affine blocks should drop the terminator. PiperOrigin-RevId: 240536998
2019-03-27 20:11:58 +08:00
"affine.terminator"() : () -> ()
Recommit: Define a AffineOps dialect as well as an AffineIfOp operation. Replace all instances of IfInst with AffineIfOp and delete IfInst. PiperOrigin-RevId: 231342063
2019-01-29 13:23:53 +08:00
// CHECK-NEXT: } else {
Change syntax of regions in the generic form of operations The generic form of operations currently supports optional regions to be located after the operation type. As we are going to add a type to each region in a leading position in the region syntax, similarly to functions, it becomes ambiguous to have regions immediately after the operation type. Put regions between operands the optional list of successors in the generic operation syntax and wrap them in parentheses. The effect on the exisitng IR syntax is minimal since only three operations (`affine.for`, `affine.if` and `gpu.kernel`) currently use regions. -- PiperOrigin-RevId: 246787087
2019-05-06 16:40:13 +08:00
}, { // The else region.
Allow operations to hold a blocklist and add support for parsing/printing a block list for verbose printing. PiperOrigin-RevId: 230951462
2019-01-26 04:48:25 +08:00
// CHECK-NEXT: "add"
%z = "add"(%c, %c) : (index, index) -> index
Introduce affine terminator Due to legacy reasons (ML/CFG function separation), regions in affine control flow operations require contained blocks not to have terminators. This is inconsistent with the notion of the block and may complicate code motion between regions of affine control operations and other regions. Introduce `affine.terminator`, a special terminator operation that must be used to terminate blocks inside affine operations and transfers the control back to he region enclosing the affine operation. For brevity and readability reasons, allow `affine.for` and `affine.if` to omit the `affine.terminator` in their regions when using custom printing and parsing format. The custom parser injects the `affine.terminator` if it is missing so as to always have it present in constructed operations. Update transformations to account for the presence of terminator. In particular, most code motion transformation between loops should leave the terminator in place, and code motion between loops and non-affine blocks should drop the terminator. PiperOrigin-RevId: 240536998
2019-03-27 20:11:58 +08:00
"affine.terminator"() : () -> ()
Change syntax of regions in the generic form of operations The generic form of operations currently supports optional regions to be located after the operation type. As we are going to add a type to each region in a leading position in the region syntax, similarly to functions, it becomes ambiguous to have regions immediately after the operation type. Put regions between operands the optional list of successors in the generic operation syntax and wrap them in parentheses. The effect on the exisitng IR syntax is minimal since only three operations (`affine.for`, `affine.if` and `gpu.kernel`) currently use regions. -- PiperOrigin-RevId: 246787087
2019-05-06 16:40:13 +08:00
})
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
{ condition = #set0 } : (index, index, index) -> ()
Change syntax of regions in the generic form of operations The generic form of operations currently supports optional regions to be located after the operation type. As we are going to add a type to each region in a leading position in the region syntax, similarly to functions, it becomes ambiguous to have regions immediately after the operation type. Put regions between operands the optional list of successors in the generic operation syntax and wrap them in parentheses. The effect on the exisitng IR syntax is minimal since only three operations (`affine.for`, `affine.if` and `gpu.kernel`) currently use regions. -- PiperOrigin-RevId: 246787087
2019-05-06 16:40:13 +08:00
return
}
// CHECK-LABEL: func @terminator_with_regions
func @terminator_with_regions() {
// Combine successors and regions in the same operation.
// CHECK: "region"()[^bb1] ( {
// CHECK: }) : () -> ()
"region"()[^bb2] ({}) : () -> ()
^bb2:
Allow operations to hold a blocklist and add support for parsing/printing a block list for verbose printing. PiperOrigin-RevId: 230951462
2019-01-26 04:48:25 +08:00
return
}
Remove the restriction that only registered terminator operations may terminate a block and have block operands. This allows for any operation to hold block operands. It also introduces the notion that unregistered operations may terminate a block. As such, the 'isTerminator' api on Instruction has been split into 'isKnownTerminator' and 'isKnownNonTerminator'. PiperOrigin-RevId: 233076831
2019-02-09 01:52:26 +08:00
// CHECK-LABEL: func @unregistered_term
func @unregistered_term(%arg0 : i1) -> i1 {
[mlir] Remove successor operands from the Operation class Summary: This revision removes all of the functionality related to successor operands on the core Operation class. This greatly simplifies a lot of handling of operands, as well as successors. For example, DialectConversion no longer needs a special "matchAndRewrite" for branching terminator operations.(Note, the existing method was also broken for operations with variadic successors!!) This also enables terminator operations to define their own relationships with successor arguments, instead of the hardcoded "pass-through" behavior that exists today. Differential Revision: https://reviews.llvm.org/D75318
2020-03-06 04:48:28 +08:00
// CHECK-NEXT: "unregistered_br"(%{{.*}})[^bb1] : (i1) -> ()
"unregistered_br"(%arg0)[^bb1] : (i1) -> ()
Remove the restriction that only registered terminator operations may terminate a block and have block operands. This allows for any operation to hold block operands. It also introduces the notion that unregistered operations may terminate a block. As such, the 'isTerminator' api on Instruction has been split into 'isKnownTerminator' and 'isKnownNonTerminator'. PiperOrigin-RevId: 233076831
2019-02-09 01:52:26 +08:00
^bb1(%arg1 : i1):
return %arg1 : i1
}
Add parser support for internal named attributes. These are attributes with names starting with ':'. PiperOrigin-RevId: 235774810
2019-02-27 04:52:51 +08:00
Introduce the notion of dialect attributes and dependent attributes. A dialect attribute derives its context from a specific dialect, whereas a dependent attribute derives context from what it is attached to. Following this, we now enforce that functions and function arguments may only contain dialect specific attributes. These are generic entities and cannot provide any specific context for a dependent attribute. Dialect attributes are defined as: dialect-namespace `.` attr-name `:` attribute-value Dialects can override any of the following hooks to verify the validity of a given attribute: * verifyFunctionAttribute * verifyFunctionArgAttribute * verifyInstructionAttribute PiperOrigin-RevId: 236507970
2019-03-03 14:34:18 +08:00
// CHECK-LABEL: func @dialect_attrs
func @dialect_attrs()
Don't force newline before function attributes Due to legacy reasons, a newline character followed by two spaces was always inserted before the attributes of the function Op in pretty form. This breaks formatting when functions are nested in some other operations. Don't print the newline and just put the attributes on the same line, which is also more consistent with module Op. Line breaking aware of indentation can be introduced separately into the parser if deemed useful. PiperOrigin-RevId: 281721793
2019-11-21 20:24:52 +08:00
// CHECK: attributes {dialect.attr = 10
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
attributes {dialect.attr = 10} {
Add parser support for internal named attributes. These are attributes with names starting with ':'. PiperOrigin-RevId: 235774810
2019-02-27 04:52:51 +08:00
return
}
Allow function names to have a leading underscore. This matches what is already defined in the spec, but not supported in the implementation. PiperOrigin-RevId: 235823663
2019-02-27 09:11:24 +08:00
// CHECK-LABEL: func @_valid.function$name
func @_valid.function$name()
Add support for named function argument attributes. The attribute dictionary is printed after the argument type: func @arg_attrs(i32 {arg_attr: 10}) func @arg_attrs(%arg0: i32 {arg_attr: 10}) PiperOrigin-RevId: 236136830
2019-03-01 01:30:52 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK-LABEL: func @external_func_arg_attrs(i32, i1 {dialect.attr = 10 : i64}, i32)
func @external_func_arg_attrs(i32, i1 {dialect.attr = 10 : i64}, i32)
Add support for named function argument attributes. The attribute dictionary is printed after the argument type: func @arg_attrs(i32 {arg_attr: 10}) func @arg_attrs(%arg0: i32 {arg_attr: 10}) PiperOrigin-RevId: 236136830
2019-03-01 01:30:52 +08:00
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK-LABEL: func @func_arg_attrs(%{{.*}}: i1 {dialect.attr = 10 : i64})
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
func @func_arg_attrs(%arg0: i1 {dialect.attr = 10 : i64}) {
Add support for named function argument attributes. The attribute dictionary is printed after the argument type: func @arg_attrs(i32 {arg_attr: 10}) func @arg_attrs(%arg0: i32 {arg_attr: 10}) PiperOrigin-RevId: 236136830
2019-03-01 01:30:52 +08:00
return
}
Add support for a standard TupleType. Though this is a standard type, it merely provides a common mechanism for representing tuples in MLIR. It is up to dialect authors to provides operations for manipulating them, e.g. extract_tuple_element. TupleType has the following form: tuple-type ::= `tuple` `<` (type (`,` type)*)? `>` Example: // Empty tuple. tuple<> // Single element. tuple<i32> // Multi element. tuple<i32, tuple<f32>, i16> PiperOrigin-RevId: 239226021
2019-03-20 01:59:02 +08:00
Add support for function result attributes. This allows dialect-specific attributes to be attached to func results. (or more specifically, FunctionLike ops). For example: ``` func @f() -> (i32 {my_dialect.some_attr = 3}) ``` This attaches my_dialect.some_attr with value 3 to the first result of func @f. Another more complex example: ``` func @g() -> (i32, f32 {my_dialect.some_attr = "foo", other_dialect.some_other_attr = [1,2,3]}, i1) ``` Here, the second result has two attributes attached. PiperOrigin-RevId: 275564165
2019-10-19 07:02:56 +08:00
// CHECK-LABEL: func @func_result_attrs({{.*}}) -> (f32 {dialect.attr = 1 : i64})
func @func_result_attrs(%arg0: f32) -> (f32 {dialect.attr = 1}) {
return %arg0 : f32
}
Add support for a standard TupleType. Though this is a standard type, it merely provides a common mechanism for representing tuples in MLIR. It is up to dialect authors to provides operations for manipulating them, e.g. extract_tuple_element. TupleType has the following form: tuple-type ::= `tuple` `<` (type (`,` type)*)? `>` Example: // Empty tuple. tuple<> // Single element. tuple<i32> // Multi element. tuple<i32, tuple<f32>, i16> PiperOrigin-RevId: 239226021
2019-03-20 01:59:02 +08:00
// CHECK-LABEL: func @empty_tuple(tuple<>)
func @empty_tuple(tuple<>)
// CHECK-LABEL: func @tuple_single_element(tuple<i32>)
func @tuple_single_element(tuple<i32>)
// CHECK-LABEL: func @tuple_multi_element(tuple<i32, i16, f32>)
func @tuple_multi_element(tuple<i32, i16, f32>)
// CHECK-LABEL: func @tuple_nested(tuple<tuple<tuple<i32>>>)
func @tuple_nested(tuple<tuple<tuple<i32>>>)
Change the muli-return syntax for operations. The name of the operation result now contains the number of results that it refers to if the number of results is greater than 1. Example: %call:2 = call @multi_return() : () -> (f32, i32) use(%calltensorflow/mlir#0, %calltensorflow/mlir#1) This cl also adds parser support for uniquely named result values. This means that a test writer can now write something like: %foo, %bar = call @multi_return() : () -> (f32, i32) use(%foo, %bar) Note: The printer will still print the collapsed form. PiperOrigin-RevId: 240860058
2019-03-29 05:58:52 +08:00
// CHECK-LABEL: func @pretty_form_multi_result
func @pretty_form_multi_result() -> (i16, i16) {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}}:2 = "foo_div"() : () -> (i16, i16)
Change the muli-return syntax for operations. The name of the operation result now contains the number of results that it refers to if the number of results is greater than 1. Example: %call:2 = call @multi_return() : () -> (f32, i32) use(%calltensorflow/mlir#0, %calltensorflow/mlir#1) This cl also adds parser support for uniquely named result values. This means that a test writer can now write something like: %foo, %bar = call @multi_return() : () -> (f32, i32) use(%foo, %bar) Note: The printer will still print the collapsed form. PiperOrigin-RevId: 240860058
2019-03-29 05:58:52 +08:00
%quot, %rem = "foo_div"() : () -> (i16, i16)
return %quot, %rem : i16, i16
}
Introduce support for parsing pretty dialect types, currently with a very restricted grammar. This will make certain common types much easier to read. This is part tensorflow/mlir#1 of 2, which allows us to accept the new syntax. Part 2 will change the asmprinter to automatically use it when appropriate, which will require updating a bunch of tests. This is motivated by the EuroLLVM tutorial and cleaning up the LLVM dialect aesthetics a bit more. -- PiperOrigin-RevId: 242234821
2019-04-06 10:36:42 +08:00
Add support for parsing multiple result name groups. This allows for parsing things like: %name_1, %name_2:5, %name_3:2 = "my.op" ... This is useful for operations that have groups of variadic result values. The total number of results is expected to match the number of results defined by the operation. PiperOrigin-RevId: 276703280
2019-10-26 00:33:32 +08:00
// CHECK-LABEL: func @pretty_form_multi_result_groups
func @pretty_form_multi_result_groups() -> (i16, i16, i16, i16, i16) {
// CHECK: %[[RES:.*]]:5 =
// CHECK: return %[[RES]]#0, %[[RES]]#1, %[[RES]]#2, %[[RES]]#3, %[[RES]]#4
%group_1:2, %group_2, %group_3:2 = "foo_test"() : () -> (i16, i16, i16, i16, i16)
return %group_1#0, %group_1#1, %group_2, %group_3#0, %group_3#1 : i16, i16, i16, i16, i16
}
Add support for parsing/printing dialect defined attributes. This also adds support for a pretty syntax for dialects attributes that is synonymous with the pretty syntax for dialect types. This cl also adds a new attribute 'OpaqueAttr' that allows for roundtripping attributes attached to unregistered dialects. Dialect attributes have the following syntax: dialect-attribute ::= `#` dialect-namespace `<` `"` attr-data `"` `>` dialect-attribute ::= `#` alias-name pretty-dialect-sym-body? -- PiperOrigin-RevId: 248344416
2019-05-16 00:10:52 +08:00
// CHECK-LABEL: func @pretty_dialect_attribute()
func @pretty_dialect_attribute() {
Allow '_' when pretty printing dialect symbols '_' is used frequently enough as the separator of words in symbols. We should allow it in dialect symbols when considering pretty printing. Also updated LangRef.md regarding pretty form. PiperOrigin-RevId: 275312494
2019-10-18 03:23:47 +08:00
// CHECK: "foo.unknown_op"() {foo = #foo.simple_attr} : () -> ()
"foo.unknown_op"() {foo = #foo.simple_attr} : () -> ()
Add support for parsing/printing dialect defined attributes. This also adds support for a pretty syntax for dialects attributes that is synonymous with the pretty syntax for dialect types. This cl also adds a new attribute 'OpaqueAttr' that allows for roundtripping attributes attached to unregistered dialects. Dialect attributes have the following syntax: dialect-attribute ::= `#` dialect-namespace `<` `"` attr-data `"` `>` dialect-attribute ::= `#` alias-name pretty-dialect-sym-body? -- PiperOrigin-RevId: 248344416
2019-05-16 00:10:52 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo.unknown_op"() {foo = #foo.complexattr<abcd>} : () -> ()
"foo.unknown_op"() {foo = #foo.complexattr<abcd>} : () -> ()
Add support for parsing/printing dialect defined attributes. This also adds support for a pretty syntax for dialects attributes that is synonymous with the pretty syntax for dialect types. This cl also adds a new attribute 'OpaqueAttr' that allows for roundtripping attributes attached to unregistered dialects. Dialect attributes have the following syntax: dialect-attribute ::= `#` dialect-namespace `<` `"` attr-data `"` `>` dialect-attribute ::= `#` alias-name pretty-dialect-sym-body? -- PiperOrigin-RevId: 248344416
2019-05-16 00:10:52 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo.unknown_op"() {foo = #foo.complexattr<abcd<f32>>} : () -> ()
"foo.unknown_op"() {foo = #foo.complexattr<abcd<f32>>} : () -> ()
Add support for parsing/printing dialect defined attributes. This also adds support for a pretty syntax for dialects attributes that is synonymous with the pretty syntax for dialect types. This cl also adds a new attribute 'OpaqueAttr' that allows for roundtripping attributes attached to unregistered dialects. Dialect attributes have the following syntax: dialect-attribute ::= `#` dialect-namespace `<` `"` attr-data `"` `>` dialect-attribute ::= `#` alias-name pretty-dialect-sym-body? -- PiperOrigin-RevId: 248344416
2019-05-16 00:10:52 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo.unknown_op"() {foo = #foo.complexattr<abcd<[f]$$[32]>>} : () -> ()
"foo.unknown_op"() {foo = #foo.complexattr<abcd<[f]$$[32]>>} : () -> ()
Add support for parsing/printing dialect defined attributes. This also adds support for a pretty syntax for dialects attributes that is synonymous with the pretty syntax for dialect types. This cl also adds a new attribute 'OpaqueAttr' that allows for roundtripping attributes attached to unregistered dialects. Dialect attributes have the following syntax: dialect-attribute ::= `#` dialect-namespace `<` `"` attr-data `"` `>` dialect-attribute ::= `#` alias-name pretty-dialect-sym-body? -- PiperOrigin-RevId: 248344416
2019-05-16 00:10:52 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo.unknown_op"() {foo = #foo.dialect<!x@#!@#>} : () -> ()
"foo.unknown_op"() {foo = #foo.dialect<!x@#!@#>} : () -> ()
Add support for parsing/printing dialect defined attributes. This also adds support for a pretty syntax for dialects attributes that is synonymous with the pretty syntax for dialect types. This cl also adds a new attribute 'OpaqueAttr' that allows for roundtripping attributes attached to unregistered dialects. Dialect attributes have the following syntax: dialect-attribute ::= `#` dialect-namespace `<` `"` attr-data `"` `>` dialect-attribute ::= `#` alias-name pretty-dialect-sym-body? -- PiperOrigin-RevId: 248344416
2019-05-16 00:10:52 +08:00
// Extraneous extra > character can't use the pretty syntax.
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK: "foo.unknown_op"() {foo = #foo<"dialect<!x@#!@#>>">} : () -> ()
"foo.unknown_op"() {foo = #foo<"dialect<!x@#!@#>>">} : () -> ()
Add support for parsing/printing dialect defined attributes. This also adds support for a pretty syntax for dialects attributes that is synonymous with the pretty syntax for dialect types. This cl also adds a new attribute 'OpaqueAttr' that allows for roundtripping attributes attached to unregistered dialects. Dialect attributes have the following syntax: dialect-attribute ::= `#` dialect-namespace `<` `"` attr-data `"` `>` dialect-attribute ::= `#` alias-name pretty-dialect-sym-body? -- PiperOrigin-RevId: 248344416
2019-05-16 00:10:52 +08:00
return
}
Introduce support for parsing pretty dialect types, currently with a very restricted grammar. This will make certain common types much easier to read. This is part tensorflow/mlir#1 of 2, which allows us to accept the new syntax. Part 2 will change the asmprinter to automatically use it when appropriate, which will require updating a bunch of tests. This is motivated by the EuroLLVM tutorial and cleaning up the LLVM dialect aesthetics a bit more. -- PiperOrigin-RevId: 242234821
2019-04-06 10:36:42 +08:00
// CHECK-LABEL: func @pretty_dialect_type()
func @pretty_dialect_type() {
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = "foo.unknown_op"() : () -> !foo.simpletype
Introduce support for parsing pretty dialect types, currently with a very restricted grammar. This will make certain common types much easier to read. This is part tensorflow/mlir#1 of 2, which allows us to accept the new syntax. Part 2 will change the asmprinter to automatically use it when appropriate, which will require updating a bunch of tests. This is motivated by the EuroLLVM tutorial and cleaning up the LLVM dialect aesthetics a bit more. -- PiperOrigin-RevId: 242234821
2019-04-06 10:36:42 +08:00
%0 = "foo.unknown_op"() : () -> !foo.simpletype
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = "foo.unknown_op"() : () -> !foo.complextype<abcd>
Introduce support for parsing pretty dialect types, currently with a very restricted grammar. This will make certain common types much easier to read. This is part tensorflow/mlir#1 of 2, which allows us to accept the new syntax. Part 2 will change the asmprinter to automatically use it when appropriate, which will require updating a bunch of tests. This is motivated by the EuroLLVM tutorial and cleaning up the LLVM dialect aesthetics a bit more. -- PiperOrigin-RevId: 242234821
2019-04-06 10:36:42 +08:00
%1 = "foo.unknown_op"() : () -> !foo.complextype<abcd>
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = "foo.unknown_op"() : () -> !foo.complextype<abcd<f32>>
Introduce support for parsing pretty dialect types, currently with a very restricted grammar. This will make certain common types much easier to read. This is part tensorflow/mlir#1 of 2, which allows us to accept the new syntax. Part 2 will change the asmprinter to automatically use it when appropriate, which will require updating a bunch of tests. This is motivated by the EuroLLVM tutorial and cleaning up the LLVM dialect aesthetics a bit more. -- PiperOrigin-RevId: 242234821
2019-04-06 10:36:42 +08:00
%2 = "foo.unknown_op"() : () -> !foo.complextype<abcd<f32>>
Expand the pretty dialect type system to support arbitrary punctuation and other characters within the <>'s now that we can. This will allow quantized types to use the pretty syntax (among others) after a few changes. -- PiperOrigin-RevId: 243521268
2019-04-15 04:41:09 +08:00
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = "foo.unknown_op"() : () -> !foo.complextype<abcd<[f]$$[32]>>
Expand the pretty dialect type system to support arbitrary punctuation and other characters within the <>'s now that we can. This will allow quantized types to use the pretty syntax (among others) after a few changes. -- PiperOrigin-RevId: 243521268
2019-04-15 04:41:09 +08:00
%3 = "foo.unknown_op"() : () -> !foo.complextype<abcd<[f]$$[32]>>
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = "foo.unknown_op"() : () -> !foo.dialect<!x@#!@#>
Expand the pretty dialect type system to support arbitrary punctuation and other characters within the <>'s now that we can. This will allow quantized types to use the pretty syntax (among others) after a few changes. -- PiperOrigin-RevId: 243521268
2019-04-15 04:41:09 +08:00
%4 = "foo.unknown_op"() : () -> !foo.dialect<!x@#!@#>
// Extraneous extra > character can't use the pretty syntax.
Standardize the value numbering in the AsmPrinter. Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
2019-07-10 01:40:29 +08:00
// CHECK: %{{.*}} = "foo.unknown_op"() : () -> !foo<"dialect<!x@#!@#>>">
Expand the pretty dialect type system to support arbitrary punctuation and other characters within the <>'s now that we can. This will allow quantized types to use the pretty syntax (among others) after a few changes. -- PiperOrigin-RevId: 243521268
2019-04-15 04:41:09 +08:00
%5 = "foo.unknown_op"() : () -> !foo<"dialect<!x@#!@#>>">
Introduce support for parsing pretty dialect types, currently with a very restricted grammar. This will make certain common types much easier to read. This is part tensorflow/mlir#1 of 2, which allows us to accept the new syntax. Part 2 will change the asmprinter to automatically use it when appropriate, which will require updating a bunch of tests. This is motivated by the EuroLLVM tutorial and cleaning up the LLVM dialect aesthetics a bit more. -- PiperOrigin-RevId: 242234821
2019-04-06 10:36:42 +08:00
return
}
Add support for a NoneType. none-type ::= `none` The `none` type is a unit type, i.e. a type with exactly one possible value, where its value does not have a defined dynamic representation. -- PiperOrigin-RevId: 245599248
2019-04-28 09:35:04 +08:00
// CHECK-LABEL: func @none_type
func @none_type() {
// CHECK: "foo.unknown_op"() : () -> none
%none_val = "foo.unknown_op"() : () -> none
return
}
Restructure the parser to support nested name scopes. This allows for regions at the same level of nesting to have values with the same SSA name. This is a necessary step for representing functions as operations. The following is now valid IR: foo.op ... { %val = ... }, { %val = ... } PiperOrigin-RevId: 251249875
2019-06-04 00:43:22 +08:00
// CHECK-LABEL: func @scoped_names
func @scoped_names() {
// CHECK-NEXT: "foo.region_op"
"foo.region_op"() ({
// CHECK-NEXT: "foo.unknown_op"
%scoped_name = "foo.unknown_op"() : () -> none
"foo.terminator"() : () -> ()
}, {
// CHECK: "foo.unknown_op"
%scoped_name = "foo.unknown_op"() : () -> none
"foo.terminator"() : () -> ()
}) : () -> ()
return
}
Refactor the location classes to be attributes instead of separate IR classes. This will allow for locations to be used in the same contexts as attributes. Given that attributes are nullable types, the 'Location' class now represents a non-nullable wrapper around a 'LocationAttr'. This preserves the desired semantics we have for non-optional locations. PiperOrigin-RevId: 254505278
2019-06-22 09:27:49 +08:00
Change the attribute dictionary syntax to separate name and value with '='. The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations: Old: "foo: 10 : i32" New: "foo = 10 : i32" PiperOrigin-RevId: 255097928
2019-06-26 10:06:06 +08:00
// CHECK-LABEL: func @loc_attr(i1 {foo.loc_attr = loc(callsite("foo" at "mysource.cc":10:8))})
func @loc_attr(i1 {foo.loc_attr = loc(callsite("foo" at "mysource.cc":10:8))})
Add support for parsing/printing the trailing type of a dialect attribute. This cl standardizes the printing of the type of dialect attributes to work the same as other attribute kinds. The type of dialect attributes will trail the dialect specific portion: `#` dialect-namespace `<` attr-data `>` `:` type The attribute parsing hooks on Dialect have been updated to take an optionally null expected type for the attribute. This matches the respective parseAttribute hooks in the OpAsmParser. PiperOrigin-RevId: 258661298
2019-07-18 07:05:32 +08:00
// CHECK-LABEL: func @dialect_attribute_with_type
func @dialect_attribute_with_type() {
// CHECK-NEXT: foo = #foo.attr : i32
"foo.unknown_op"() {foo = #foo.attr : i32} : () -> ()
}
Add support for hexadecimal float literals MLIR does not have support for parsing special floating point values such as infinities and NaNs. If programmatically constructed, these values are printed as NaN and (+-)Inf and cannot be parsed back. Add parser support for hexadecimal literals in float attributes, following LLVM IR. The literal corresponds to the in-memory representation of the floating point value. IEEE 754 defines a range of possible values for NaNs, storing the bitwise representation allows MLIR to properly roundtrip NaNs with different bit values of significands. The initial version of this commit was missing support for float literals that used to be printed in decimal notation as a fallback, but ended up being printed in hexadecimal format which became the fallback for special values. The decimal fallback behavior was not exercised by tests. It is currently reinstated and tested by the newly added test @f32_potential_precision_loss in parser.mlir. PiperOrigin-RevId: 260790900
2019-07-31 05:05:49 +08:00
// CHECK-LABEL: @f16_special_values
func @f16_special_values() {
// F16 NaNs.
// CHECK: constant 0x7C01 : f16
%0 = constant 0x7C01 : f16
// CHECK: constant 0x7FFF : f16
%1 = constant 0x7FFF : f16
// CHECK: constant 0xFFFF : f16
%2 = constant 0xFFFF : f16
// F16 positive infinity.
// CHECK: constant 0x7C00 : f16
%3 = constant 0x7C00 : f16
Fix minor spelling tweaks (NFC) Closes tensorflow/mlir#175 PiperOrigin-RevId: 275726876
2019-10-21 00:44:06 +08:00
// F16 negative infinity.
Add support for hexadecimal float literals MLIR does not have support for parsing special floating point values such as infinities and NaNs. If programmatically constructed, these values are printed as NaN and (+-)Inf and cannot be parsed back. Add parser support for hexadecimal literals in float attributes, following LLVM IR. The literal corresponds to the in-memory representation of the floating point value. IEEE 754 defines a range of possible values for NaNs, storing the bitwise representation allows MLIR to properly roundtrip NaNs with different bit values of significands. The initial version of this commit was missing support for float literals that used to be printed in decimal notation as a fallback, but ended up being printed in hexadecimal format which became the fallback for special values. The decimal fallback behavior was not exercised by tests. It is currently reinstated and tested by the newly added test @f32_potential_precision_loss in parser.mlir. PiperOrigin-RevId: 260790900
2019-07-31 05:05:49 +08:00
// CHECK: constant 0xFC00 : f16
%4 = constant 0xFC00 : f16
return
}
// CHECK-LABEL: @f32_special_values
func @f32_special_values() {
// F32 signaling NaNs.
// CHECK: constant 0x7F800001 : f32
%0 = constant 0x7F800001 : f32
// CHECK: constant 0x7FBFFFFF : f32
%1 = constant 0x7FBFFFFF : f32
// F32 quiet NaNs.
// CHECK: constant 0x7FC00000 : f32
%2 = constant 0x7FC00000 : f32
// CHECK: constant 0xFFFFFFFF : f32
%3 = constant 0xFFFFFFFF : f32
// F32 positive infinity.
// CHECK: constant 0x7F800000 : f32
%4 = constant 0x7F800000 : f32
// F32 negative infinity.
// CHECK: constant 0xFF800000 : f32
%5 = constant 0xFF800000 : f32
return
}
// CHECK-LABEL: @f64_special_values
func @f64_special_values() {
// F64 signaling NaNs.
// CHECK: constant 0x7FF0000000000001 : f64
%0 = constant 0x7FF0000000000001 : f64
// CHECK: constant 0x7FF8000000000000 : f64
%1 = constant 0x7FF8000000000000 : f64
// F64 quiet NaNs.
// CHECK: constant 0x7FF0000001000000 : f64
%2 = constant 0x7FF0000001000000 : f64
// CHECK: constant 0xFFF0000001000000 : f64
%3 = constant 0xFFF0000001000000 : f64
Fix minor spelling tweaks (NFC) Closes tensorflow/mlir#175 PiperOrigin-RevId: 275726876
2019-10-21 00:44:06 +08:00
// F64 positive infinity.
Add support for hexadecimal float literals MLIR does not have support for parsing special floating point values such as infinities and NaNs. If programmatically constructed, these values are printed as NaN and (+-)Inf and cannot be parsed back. Add parser support for hexadecimal literals in float attributes, following LLVM IR. The literal corresponds to the in-memory representation of the floating point value. IEEE 754 defines a range of possible values for NaNs, storing the bitwise representation allows MLIR to properly roundtrip NaNs with different bit values of significands. The initial version of this commit was missing support for float literals that used to be printed in decimal notation as a fallback, but ended up being printed in hexadecimal format which became the fallback for special values. The decimal fallback behavior was not exercised by tests. It is currently reinstated and tested by the newly added test @f32_potential_precision_loss in parser.mlir. PiperOrigin-RevId: 260790900
2019-07-31 05:05:49 +08:00
// CHECK: constant 0x7FF0000000000000 : f64
%4 = constant 0x7FF0000000000000 : f64
// F64 negative infinity.
// CHECK: constant 0xFFF0000000000000 : f64
%5 = constant 0xFFF0000000000000 : f64
[mlir][AsmPrinter] Fix edge case when printing floating point values. Summary: In some edge cases the default APFloat printer will generate something that we can't parse back in. In these cases, fallback to using hex instead. Differential Revision: https://reviews.llvm.org/D74181
2020-02-07 10:05:32 +08:00
// Check that values that can't be represented with the default format, use
// hex instead.
// CHECK: constant 0xC1CDC00000000000 : f64
%6 = constant 0xC1CDC00000000000 : f64
Add support for hexadecimal float literals MLIR does not have support for parsing special floating point values such as infinities and NaNs. If programmatically constructed, these values are printed as NaN and (+-)Inf and cannot be parsed back. Add parser support for hexadecimal literals in float attributes, following LLVM IR. The literal corresponds to the in-memory representation of the floating point value. IEEE 754 defines a range of possible values for NaNs, storing the bitwise representation allows MLIR to properly roundtrip NaNs with different bit values of significands. The initial version of this commit was missing support for float literals that used to be printed in decimal notation as a fallback, but ended up being printed in hexadecimal format which became the fallback for special values. The decimal fallback behavior was not exercised by tests. It is currently reinstated and tested by the newly added test @f32_potential_precision_loss in parser.mlir. PiperOrigin-RevId: 260790900
2019-07-31 05:05:49 +08:00
return
}
[mlir] Use double format when parsing bfloat16 hexadecimal values Summary: bfloat16 doesn't have a valid APFloat format, so we have to use double semantics when storing it. This change makes sure that hexadecimal values can be round-tripped properly given this fact. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D72667
2020-01-15 05:47:21 +08:00
// CHECK-LABEL: @bfloat16_special_values
func @bfloat16_special_values() {
// bfloat16 signaling NaNs.
[mlir] Fix representation of BF16 constants This patch is a follow-up on https://reviews.llvm.org/D81127 BF16 constants were represented as 64-bit floating point values due to the lack of support for BF16 in APFloat. APFloat was recently extended to support BF16 so this patch is fixing the BF16 constant representation to be 16-bit. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D81218
2020-06-06 08:29:56 +08:00
// CHECK: constant 0x7F81 : bf16
%0 = constant 0x7F81 : bf16
// CHECK: constant 0xFF81 : bf16
%1 = constant 0xFF81 : bf16
[mlir] Use double format when parsing bfloat16 hexadecimal values Summary: bfloat16 doesn't have a valid APFloat format, so we have to use double semantics when storing it. This change makes sure that hexadecimal values can be round-tripped properly given this fact. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D72667
2020-01-15 05:47:21 +08:00
// bfloat16 quiet NaNs.
[mlir] Fix representation of BF16 constants This patch is a follow-up on https://reviews.llvm.org/D81127 BF16 constants were represented as 64-bit floating point values due to the lack of support for BF16 in APFloat. APFloat was recently extended to support BF16 so this patch is fixing the BF16 constant representation to be 16-bit. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D81218
2020-06-06 08:29:56 +08:00
// CHECK: constant 0x7FC0 : bf16
%2 = constant 0x7FC0 : bf16
// CHECK: constant 0xFFC0 : bf16
%3 = constant 0xFFC0 : bf16
[mlir] Use double format when parsing bfloat16 hexadecimal values Summary: bfloat16 doesn't have a valid APFloat format, so we have to use double semantics when storing it. This change makes sure that hexadecimal values can be round-tripped properly given this fact. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D72667
2020-01-15 05:47:21 +08:00
// bfloat16 positive infinity.
[mlir] Fix representation of BF16 constants This patch is a follow-up on https://reviews.llvm.org/D81127 BF16 constants were represented as 64-bit floating point values due to the lack of support for BF16 in APFloat. APFloat was recently extended to support BF16 so this patch is fixing the BF16 constant representation to be 16-bit. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D81218
2020-06-06 08:29:56 +08:00
// CHECK: constant 0x7F80 : bf16
%4 = constant 0x7F80 : bf16
[mlir] Use double format when parsing bfloat16 hexadecimal values Summary: bfloat16 doesn't have a valid APFloat format, so we have to use double semantics when storing it. This change makes sure that hexadecimal values can be round-tripped properly given this fact. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D72667
2020-01-15 05:47:21 +08:00
// bfloat16 negative infinity.
[mlir] Fix representation of BF16 constants This patch is a follow-up on https://reviews.llvm.org/D81127 BF16 constants were represented as 64-bit floating point values due to the lack of support for BF16 in APFloat. APFloat was recently extended to support BF16 so this patch is fixing the BF16 constant representation to be 16-bit. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D81218
2020-06-06 08:29:56 +08:00
// CHECK: constant 0xFF80 : bf16
%5 = constant 0xFF80 : bf16
[mlir] Use double format when parsing bfloat16 hexadecimal values Summary: bfloat16 doesn't have a valid APFloat format, so we have to use double semantics when storing it. This change makes sure that hexadecimal values can be round-tripped properly given this fact. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D72667
2020-01-15 05:47:21 +08:00
return
}
Add support for hexadecimal float literals MLIR does not have support for parsing special floating point values such as infinities and NaNs. If programmatically constructed, these values are printed as NaN and (+-)Inf and cannot be parsed back. Add parser support for hexadecimal literals in float attributes, following LLVM IR. The literal corresponds to the in-memory representation of the floating point value. IEEE 754 defines a range of possible values for NaNs, storing the bitwise representation allows MLIR to properly roundtrip NaNs with different bit values of significands. The initial version of this commit was missing support for float literals that used to be printed in decimal notation as a fallback, but ended up being printed in hexadecimal format which became the fallback for special values. The decimal fallback behavior was not exercised by tests. It is currently reinstated and tested by the newly added test @f32_potential_precision_loss in parser.mlir. PiperOrigin-RevId: 260790900
2019-07-31 05:05:49 +08:00
// We want to print floats in exponential notation with 6 significant digits,
// but it may lead to precision loss when parsing back, in which case we print
// the decimal form instead.
// CHECK-LABEL: @f32_potential_precision_loss()
func @f32_potential_precision_loss() {
// CHECK: constant -1.23697901 : f32
%0 = constant -1.23697901 : f32
return
}
Support hexadecimal floats in tensor literals Extend the recently introduced support for hexadecimal float literals to tensor literals, which may also contain special floating point values such as infinities and NaNs. Modify TensorLiteralParser to store the list of tokens representing values until the type is parsed instead of trying to guess the tensor element type from the token kinds (hexadecimal values can be either integers or floats, and can be mixed with both). Maintain the error reports as close as possible to the existing implementation to avoid disturbing the tests. They can be improved in a separate clean-up if deemed necessary. PiperOrigin-RevId: 260794716
2019-07-31 05:24:30 +08:00
// CHECK-LABEL: @special_float_values_in_tensors
func @special_float_values_in_tensors() {
// CHECK: dense<0xFFFFFFFF> : tensor<4x4xf32>
"foo"(){bar = dense<0xFFFFFFFF> : tensor<4x4xf32>} : () -> ()
// CHECK: dense<[{{\[}}0xFFFFFFFF, 0x7F800000], [0x7FBFFFFF, 0x7F800001]]> : tensor<2x2xf32>
"foo"(){bar = dense<[[0xFFFFFFFF, 0x7F800000], [0x7FBFFFFF, 0x7F800001]]> : tensor<2x2xf32>} : () -> ()
// CHECK: dense<[0xFFFFFFFF, 0.000000e+00]> : tensor<2xf32>
"foo"(){bar = dense<[0xFFFFFFFF, 0.0]> : tensor<2xf32>} : () -> ()
// CHECK: sparse<[{{\[}}1, 1, 0], [0, 1, 1]], [0xFFFFFFFF, 0x7F800001]>
"foo"(){bar = sparse<[[1,1,0],[0,1,1]], [0xFFFFFFFF, 0x7F800001]> : tensor<2x2x2xf32>} : () -> ()
}
Allow isolated regions to form isolated SSA name scopes in the printer. This will allow for naming values the same as existing SSA values for regions attached to operations that are isolated from above. This fits in with how the system already allows separate name scopes for sibling regions. This name shadowing can be enabled in the custom parser of operations by setting the 'enableNameShadowing' flag to true when calling 'parseRegion'. %arg = constant 10 : i32 foo.op { %arg = constant 10 : i32 } PiperOrigin-RevId: 264255999
2019-08-20 06:26:43 +08:00
// Test parsing of an op with multiple region arguments, and without a
// delimiter.
// CHECK-LABEL: func @op_with_region_args
func @op_with_region_args() {
// CHECK: "test.polyfor"() ( {
// CHECK-NEXT: ^bb{{.*}}(%{{.*}}: index, %{{.*}}: index, %{{.*}}: index):
test.polyfor %i, %j, %k {
"foo"() : () -> ()
}
return
}
// Test allowing different name scopes for regions isolated from above.
// CHECK-LABEL: func @op_with_passthrough_region_args
func @op_with_passthrough_region_args() {
// CHECK: [[VAL:%.*]] = constant
%0 = constant 10 : index
Introduce the ability for "isolated from above" ops to introduce shadowing names for the basic block arguments in their body. PiperOrigin-RevId: 265084627
2019-08-24 01:35:24 +08:00
// CHECK: test.isolated_region [[VAL]] {
// CHECK-NEXT: "foo.consumer"([[VAL]]) : (index)
// CHECK-NEXT: }
Allow isolated regions to form isolated SSA name scopes in the printer. This will allow for naming values the same as existing SSA values for regions attached to operations that are isolated from above. This fits in with how the system already allows separate name scopes for sibling regions. This name shadowing can be enabled in the custom parser of operations by setting the 'enableNameShadowing' flag to true when calling 'parseRegion'. %arg = constant 10 : i32 foo.op { %arg = constant 10 : i32 } PiperOrigin-RevId: 264255999
2019-08-20 06:26:43 +08:00
test.isolated_region %0 {
"foo.consumer"(%0) : (index) -> ()
}
Introduce the ability for "isolated from above" ops to introduce shadowing names for the basic block arguments in their body. PiperOrigin-RevId: 265084627
2019-08-24 01:35:24 +08:00
// CHECK: [[VAL:%.*]]:2 = "foo.op"
%result:2 = "foo.op"() : () -> (index, index)
// CHECK: test.isolated_region [[VAL]]#1 {
// CHECK-NEXT: "foo.consumer"([[VAL]]#1) : (index)
// CHECK-NEXT: }
test.isolated_region %result#1 {
"foo.consumer"(%result#1) : (index) -> ()
}
Allow isolated regions to form isolated SSA name scopes in the printer. This will allow for naming values the same as existing SSA values for regions attached to operations that are isolated from above. This fits in with how the system already allows separate name scopes for sibling regions. This name shadowing can be enabled in the custom parser of operations by setting the 'enableNameShadowing' flag to true when calling 'parseRegion'. %arg = constant 10 : i32 foo.op { %arg = constant 10 : i32 } PiperOrigin-RevId: 264255999
2019-08-20 06:26:43 +08:00
return
}
Introduce the ability for "isolated from above" ops to introduce shadowing names for the basic block arguments in their body. PiperOrigin-RevId: 265084627
2019-08-24 01:35:24 +08:00
Tweak to the pretty type parser to recognize that `->` is a special token. Tweak to the pretty type parser to recognize that `->` is a special token that shouldn't be split into two characters. This change allows dialect types to wrap function types as in `!my.ptr_type<(i32) -> i32>`. Closes tensorflow/mlir#105 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/105 from schweitzpgi:parse-arrow 8b2d768053f419daae5a1a864121a44c4319acbe PiperOrigin-RevId: 265986240
2019-08-29 04:55:11 +08:00
// CHECK-LABEL: func @ptr_to_function() -> !unreg.ptr<() -> ()>
func @ptr_to_function() -> !unreg.ptr<() -> ()>
Fix an invalid assert when processing escaped strings. The assert assumed that the escaped character could not appear at the end of the string. Fixes tensorflow/mlir#117 PiperOrigin-RevId: 266975471
2019-09-04 02:27:00 +08:00
// CHECK-LABEL: func @escaped_string_char(i1 {foo.value = "\0A"})
func @escaped_string_char(i1 {foo.value = "\n"})
Add support to OpAsmParser for parsing unknown keywords. This is useful in several cases, for example a user may want to sugar the syntax of a string(as we do with custom operation syntax), or avoid many nested ifs for parsing a set of known keywords. PiperOrigin-RevId: 269695451
2019-09-18 08:54:54 +08:00
// CHECK-LABEL: func @wrapped_keyword_test
func @wrapped_keyword_test() {
// CHECK: test.wrapped_keyword foo.keyword
test.wrapped_keyword foo.keyword
return
}
Add support for parsing/printing non bare-identifier SymbolRefs. The restriction that symbols can only have identifier names is arbitrary, and artificially limits the names that a symbol may have. This change adds support for parsing and printing symbols that don't fit in the 'bare-identifier' grammar by printing the reference in quotes, e.g. @"0_my_reference" can now be used as a symbol name. PiperOrigin-RevId: 273644768
2019-10-09 08:44:39 +08:00
// CHECK-LABEL: func @"\22_string_symbol_reference\22"
func @"\"_string_symbol_reference\""() {
// CHECK: ref = @"\22_string_symbol_reference\22"
"foo.symbol_reference"() {ref = @"\"_string_symbol_reference\""} : () -> ()
return
}
Add support for nested symbol references. This change allows for adding additional nested references to a SymbolRefAttr to allow for further resolving a symbol if that symbol also defines a SymbolTable. If a referenced symbol also defines a symbol table, a nested reference can be used to refer to a symbol within that table. Nested references are printed after the main reference in the following form: symbol-ref-attribute ::= symbol-ref-id (`::` symbol-ref-id)* Example: module @reference { func @nested_reference() } my_reference_op @reference::@nested_reference Given that SymbolRefAttr is now more general, the existing functionality centered around a single reference is moved to a derived class FlatSymbolRefAttr. Followup commits will add support to lookups, rauw, etc. for scoped references. PiperOrigin-RevId: 279860501
2019-11-12 10:18:02 +08:00
[mlir] Add support for non-identifier attribute names. Summary: In some situations the name of the attribute is not representable as a bare-identifier, this revision adds support for those cases by formatting the name as a string instead. This has the added benefit of removing the identifier regex from the verifier. Differential Revision: https://reviews.llvm.org/D75973
2020-03-12 04:22:19 +08:00
// CHECK-LABEL: func @string_attr_name
// CHECK-SAME: {"0 . 0", nested = {"0 . 0"}}
func @string_attr_name() attributes {"0 . 0", nested = {"0 . 0"}}
Add support for nested symbol references. This change allows for adding additional nested references to a SymbolRefAttr to allow for further resolving a symbol if that symbol also defines a SymbolTable. If a referenced symbol also defines a symbol table, a nested reference can be used to refer to a symbol within that table. Nested references are printed after the main reference in the following form: symbol-ref-attribute ::= symbol-ref-id (`::` symbol-ref-id)* Example: module @reference { func @nested_reference() } my_reference_op @reference::@nested_reference Given that SymbolRefAttr is now more general, the existing functionality centered around a single reference is moved to a derived class FlatSymbolRefAttr. Followup commits will add support to lookups, rauw, etc. for scoped references. PiperOrigin-RevId: 279860501
2019-11-12 10:18:02 +08:00
// CHECK-LABEL: func @nested_reference
Don't force newline before function attributes Due to legacy reasons, a newline character followed by two spaces was always inserted before the attributes of the function Op in pretty form. This breaks formatting when functions are nested in some other operations. Don't print the newline and just put the attributes on the same line, which is also more consistent with module Op. Line breaking aware of indentation can be introduced separately into the parser if deemed useful. PiperOrigin-RevId: 281721793
2019-11-21 20:24:52 +08:00
// CHECK: ref = @some_symbol::@some_nested_symbol
Add support for nested symbol references. This change allows for adding additional nested references to a SymbolRefAttr to allow for further resolving a symbol if that symbol also defines a SymbolTable. If a referenced symbol also defines a symbol table, a nested reference can be used to refer to a symbol within that table. Nested references are printed after the main reference in the following form: symbol-ref-attribute ::= symbol-ref-id (`::` symbol-ref-id)* Example: module @reference { func @nested_reference() } my_reference_op @reference::@nested_reference Given that SymbolRefAttr is now more general, the existing functionality centered around a single reference is moved to a derived class FlatSymbolRefAttr. Followup commits will add support to lookups, rauw, etc. for scoped references. PiperOrigin-RevId: 279860501
2019-11-12 10:18:02 +08:00
func @nested_reference() attributes {test.ref = @some_symbol::@some_nested_symbol }
Add a new OpAsmOpInterface to allow for ops to directly hook into the AsmPrinter. This interface provides more fine-grained hooks into the AsmPrinter than the dialect interface, allowing for operations to define the asm name to use for results directly on the operations themselves. The hook is also expanded to enable defining named result "groups". Get a special name to use when printing the results of this operation. The given callback is invoked with a specific result value that starts a result "pack", and the name to give this result pack. To signal that a result pack should use the default naming scheme, a None can be passed in instead of the name. For example, if you have an operation that has four results and you want to split these into three distinct groups you could do the following: setNameFn(getResult(0), "first_result"); setNameFn(getResult(1), "middle_results"); setNameFn(getResult(3), ""); // use the default numbering. This would print the operation as follows: %first_result, %middle_results:2, %0 = "my.op" ... PiperOrigin-RevId: 281546873
2019-11-21 02:19:01 +08:00
// CHECK-LABEL: func @custom_asm_names
func @custom_asm_names() -> (i32, i32, i32, i32, i32, i32, i32) {
// CHECK: %[[FIRST:first.*]], %[[MIDDLE:middle_results.*]]:2, %[[LAST:[0-9]+]]
%0, %1:2, %2 = "test.asm_interface_op"() : () -> (i32, i32, i32, i32)
// CHECK: %[[FIRST_2:first.*]], %[[LAST_2:[0-9]+]]
%3, %4 = "test.asm_interface_op"() : () -> (i32, i32)
// CHECK: %[[RESULT:result.*]]
%5 = "test.asm_dialect_interface_op"() : () -> (i32)
// CHECK: return %[[FIRST]], %[[MIDDLE]]#0, %[[MIDDLE]]#1, %[[LAST]], %[[FIRST_2]], %[[LAST_2]]
return %0, %1#0, %1#1, %2, %3, %4, %5 : i32, i32, i32, i32, i32, i32, i32
}
Add support for custom op parser/printer hooks to know about result names. Summary: This allows the custom parser/printer hooks to do interesting things with the SSA names. This patch: - Adds a new 'getResultName' method to OpAsmParser that allows a parser implementation to get information about its result names, along with a getNumResults() method that allows op parser impls to know how many results are expected. - Adds a OpAsmPrinter::printOperand overload that takes an explicit stream. - Adds a test.string_attr_pretty_name operation that uses these hooks to do fancy things with the result name. Reviewers: rriddle! Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D76205
2020-03-16 08:13:59 +08:00
// CHECK-LABEL: func @pretty_names
// This tests the behavior
func @pretty_names() {
// Simple case, should parse and print as %x being an implied 'name'
// attribute.
%x = test.string_attr_pretty_name
// CHECK: %x = test.string_attr_pretty_name
// CHECK-NOT: attributes
[mlir] Fix representation of BF16 constants This patch is a follow-up on https://reviews.llvm.org/D81127 BF16 constants were represented as 64-bit floating point values due to the lack of support for BF16 in APFloat. APFloat was recently extended to support BF16 so this patch is fixing the BF16 constant representation to be 16-bit. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D81218
2020-06-06 08:29:56 +08:00
Add support for custom op parser/printer hooks to know about result names. Summary: This allows the custom parser/printer hooks to do interesting things with the SSA names. This patch: - Adds a new 'getResultName' method to OpAsmParser that allows a parser implementation to get information about its result names, along with a getNumResults() method that allows op parser impls to know how many results are expected. - Adds a OpAsmPrinter::printOperand overload that takes an explicit stream. - Adds a test.string_attr_pretty_name operation that uses these hooks to do fancy things with the result name. Reviewers: rriddle! Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D76205
2020-03-16 08:13:59 +08:00
// This specifies an explicit name, which should override the result.
%YY = test.string_attr_pretty_name attributes { names = ["y"] }
// CHECK: %y = test.string_attr_pretty_name
// CHECK-NOT: attributes
[mlir] Fix representation of BF16 constants This patch is a follow-up on https://reviews.llvm.org/D81127 BF16 constants were represented as 64-bit floating point values due to the lack of support for BF16 in APFloat. APFloat was recently extended to support BF16 so this patch is fixing the BF16 constant representation to be 16-bit. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D81218
2020-06-06 08:29:56 +08:00
Add support for custom op parser/printer hooks to know about result names. Summary: This allows the custom parser/printer hooks to do interesting things with the SSA names. This patch: - Adds a new 'getResultName' method to OpAsmParser that allows a parser implementation to get information about its result names, along with a getNumResults() method that allows op parser impls to know how many results are expected. - Adds a OpAsmPrinter::printOperand overload that takes an explicit stream. - Adds a test.string_attr_pretty_name operation that uses these hooks to do fancy things with the result name. Reviewers: rriddle! Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D76205
2020-03-16 08:13:59 +08:00
// Conflicts with the 'y' name, so need an explicit attribute.
%0 = "test.string_attr_pretty_name"() { names = ["y"]} : () -> i32
// CHECK: %y_0 = test.string_attr_pretty_name attributes {names = ["y"]}
// Name contains a space.
%1 = "test.string_attr_pretty_name"() { names = ["space name"]} : () -> i32
// CHECK: %space_name = test.string_attr_pretty_name attributes {names = ["space name"]}
"unknown.use"(%x, %YY, %0, %1) : (i32, i32, i32, i32) -> ()
// Multi-result support.
%a, %b, %c = test.string_attr_pretty_name
// CHECK: %a, %b, %c = test.string_attr_pretty_name
// CHECK-NOT: attributes
%q:3, %r = test.string_attr_pretty_name
// CHECK: %q, %q_1, %q_2, %r = test.string_attr_pretty_name attributes {names = ["q", "q", "q", "r"]}
// CHECK: return
return
}
[MLIR] Allow unreachable blocks to violate dominance property. It is possible for optimizations to create SSA code which violates the dominance property in unreachable blocks. Equivalently, dominance computed using normal mechanisms is undefined in unreachable blocks. See discussion here: https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/51 This patch only checks the dominance condition inside blocks which are reachable from the the entry block of their region. Note that the dominance conditions of regions contained in an unreachable block are still checked. Differential Revision: https://reviews.llvm.org/D79922
2020-05-14 13:32:21 +08:00
func @unreachable_dominance_violation_ok() -> i1 {
[mlir] Refactor BoolAttr to be a special case of IntegerAttr This simplifies a lot of handling of BoolAttr/IntegerAttr. For example, a lot of places currently have to handle both IntegerAttr and BoolAttr. In other places, a decision is made to pick one which can lead to surprising results for users. For example, DenseElementsAttr currently uses BoolAttr for i1 even if the user initialized it with an Array of i1 IntegerAttrs. Differential Revision: https://reviews.llvm.org/D81047
2020-06-03 09:20:38 +08:00
%c = constant false // CHECK: [[VAL:%.*]] = constant false
[MLIR] Allow unreachable blocks to violate dominance property. It is possible for optimizations to create SSA code which violates the dominance property in unreachable blocks. Equivalently, dominance computed using normal mechanisms is undefined in unreachable blocks. See discussion here: https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/51 This patch only checks the dominance condition inside blocks which are reachable from the the entry block of their region. Note that the dominance conditions of regions contained in an unreachable block are still checked. Differential Revision: https://reviews.llvm.org/D79922
2020-05-14 13:32:21 +08:00
return %c : i1 // CHECK: return [[VAL]] : i1
^bb1: // CHECK: ^bb1: // no predecessors
// %1 is not dominated by it's definition, but block is not reachable.
%2:3 = "bar"(%1) : (i64) -> (i1,i1,i1) // CHECK: [[VAL2:%.*]]:3 = "bar"([[VAL3:%.*]]) : (i64) -> (i1, i1, i1)
br ^bb4 // CHECK: br ^bb3
^bb2: // CHECK: ^bb2: // pred: ^bb2
br ^bb2 // CHECK: br ^bb2
^bb4: // CHECK: ^bb3: // pred: ^bb1
%1 = "foo"() : ()->i64 // CHECK: [[VAL3]] = "foo"() : () -> i64
return %2#1 : i1 // CHECK: return [[VAL2]]#1 : i1
} // CHECK: }