summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Parser
Commit message (Collapse)AuthorAgeFilesLines
...
* Add a parserSourceFile function that takes a file path directlyMehdi Amini2019-03-291-0/+17
| | | | | | This avoids adding boilerplate around the SourceMgr on the client. PiperOrigin-RevId: 239918122
* Add support for a standard TupleType. Though this is a standard type, it ↵River Riddle2019-03-292-0/+29
| | | | | | | | | | | | | | | | | | | | 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
* Add support for parsing true/false inside of a splat tensor literal.River Riddle2019-03-291-0/+2
| | | | PiperOrigin-RevId: 239052061
* Add an 'Instruction::create' overload that accepts an existing ↵River Riddle2019-03-291-1/+1
| | | | | | NamedAttributeList. This avoids the need to unique an attribute list if one already exists, e.g. when cloning an existing instruction. PiperOrigin-RevId: 238512499
* Rename BlockList into RegionAlex Zinenko2019-03-291-59/+55
| | | | | | NFC. This is step 1/n to specifying regions as parts of any operation. PiperOrigin-RevId: 238472370
* Introduce the notion of dialect attributes and dependent attributes. A ↵River Riddle2019-03-291-8/+2
| | | | | | | | | | | | | | | 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
* Set the namespace of the StandardOps dialect to "std", but add a special ↵River Riddle2019-03-291-1/+10
| | | | | | 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
* NFC. Move all of the remaining operations left in BuiltinOps to StandardOps. ↵River Riddle2019-03-291-1/+0
| | | | | | The only thing left in BuiltinOps are the core MLIR types. The standard types can't be moved because they are referenced within the IR directory, e.g. in things like Builder. PiperOrigin-RevId: 236403665
* Add support for parsing and printing affine.if and affine.for attributes. ↵River Riddle2019-03-291-2/+2
| | | | | | | | | | | | | | | | | | | | The attribute dictionaries are printed after the final block list for both operations: for %i = 0 to 10 { ... } {some_attr: true} if () : () () { ... } {some_attr: true} if () : () () { ... } else { ... } {some_attr: true} PiperOrigin-RevId: 236346983
* Provide a Builder::getNamedAttr and ↵River Riddle2019-03-291-2/+1
| | | | | | (Instruction|Function)::setAttr(StringRef, Attribute) to simplify attribute manipulation. PiperOrigin-RevId: 236222504
* Add support for named function argument attributes. The attribute dictionary ↵River Riddle2019-03-291-14/+31
| | | | | | | | | | is printed after the argument type: func @arg_attrs(i32 {arg_attr: 10}) func @arg_attrs(%arg0: i32 {arg_attr: 10}) PiperOrigin-RevId: 236136830
* When parsing, check that a region operation is not referencing any of the ↵River Riddle2019-03-291-0/+11
| | | | | | entry arguments to its block lists. PiperOrigin-RevId: 236030438
* Allow function names to have a leading underscore. This matches what is ↵River Riddle2019-03-291-3/+5
| | | | | | already defined in the spec, but not supported in the implementation. PiperOrigin-RevId: 235823663
* Validate the names of attribute, dialect, and functions during verification. ↵River Riddle2019-03-292-3/+4
| | | | | | This essentially enforces the parsing rules upon their names. PiperOrigin-RevId: 235818842
* Add parser support for internal named attributes. These are attributes with ↵River Riddle2019-03-291-2/+8
| | | | | | names starting with ':'. PiperOrigin-RevId: 235774810
* Convert the dialect type parse/print hooks into virtual functions on the ↵River Riddle2019-03-291-11/+3
| | | | | | Dialect class. PiperOrigin-RevId: 235589945
* Add langref descriptions for the attribute values supported in MLIR.River Riddle2019-03-291-6/+8
| | | | PiperOrigin-RevId: 233661338
* Add dialect-specific decoding for opaque constants.Tatiana Shpeisman2019-03-291-1/+18
| | | | | | | | Associates opaque constants with a particular dialect. Adds general mechanism to register dialect-specific hooks defined in external components. Adds hooks to decode opaque tensor constant and extract an element of an opaque tensor constant. This CL does not change the existing mechanism for registering constant folding hook yet. One thing at a time. PiperOrigin-RevId: 233544757
* Remove the restriction that only registered terminator operations may ↵River Riddle2019-03-291-1/+1
| | | | | | 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
* Disallow zero dimensions in vectors and memrefsAlex Zinenko2019-03-291-14/+7
| | | | | | | | | | | | | | | | | Aggregate types where at least one dimension is zero do not fully make sense as they cannot contain any values (their total size is zero). However, TensorFlow and XLA support tensors with zero sizes, so we must support those too. This is relatively safe since, unlike vectors and memrefs, we don't have first-class element accessors for MLIR tensors. To support sparse element attributes of vector types that have no non-zero elements, make sure that index and value element attributes have tensor type so that we never need to create a zero vector type internally. Note that this is already consistent with the inline documentation of the sparse elements attribute. Users of the sparse elements attribute should not rely on the storage schema anyway. PiperOrigin-RevId: 232896707
* Disallow hexadecimal literals in type declarationsAlex Zinenko2019-03-292-40/+43
| | | | | | | | | | | | | | | | | | | 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
* Print parens around the return type of a function if it is also a function typeAlex Zinenko2019-03-291-30/+51
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove InstWalker and move all instruction walking to the api facilities on ↵River Riddle2019-03-291-1/+0
| | | | | | Function/Block/Instruction. PiperOrigin-RevId: 232388113
* Remove remaining references to OperationInst in all directories except for ↵River Riddle2019-03-291-7/+6
| | | | | | lib/Transforms. PiperOrigin-RevId: 232322771
* Fix the handling of the resizable operands bit of OperationState in a few ↵River Riddle2019-03-291-1/+1
| | | | | | places. PiperOrigin-RevId: 232163738
* When parsing, treat an IntegerSet with no constraints as a degenerate true ↵River Riddle2019-03-291-11/+8
| | | | | | case. Also update the spec to note that affine constraints are optional. PiperOrigin-RevId: 232158673
* Emit an error when parsing an affine structure if '->' or ':' is not foundRiver Riddle2019-03-291-1/+1
| | | | | | after the dim/symbol id list. PiperOrigin-RevId: 232094789
* Minor fix to the lexer whitespace loop.Stella Laurenzo2019-03-291-1/+4
| | | | | | | | | | | | Nothing in the loop can (legally) cause curPtr -> nullptr. And if it did, we would null dereference right below anyway. This loop still reads funny to me but doesn't make me stare at it and wonder what I am missing anymore. -- PiperOrigin-RevId: 232062076
* Define the AffineForOp and replace ForInst with it. This patch is largely ↵River Riddle2019-03-291-252/+94
| | | | | | mechanical, i.e. changing usages of ForInst to OpPointer<AffineForOp>. An important difference is that upon construction an AffineForOp no longer automatically creates the body and induction variable. To generate the body/iv, 'createBody' can be called on an AffineForOp with no body. PiperOrigin-RevId: 232060516
* Define an detail::OperandStorage class to handle managing instruction ↵River Riddle2019-03-291-1/+5
| | | | | | operands. This class stores operands in a similar way to SmallVector except for two key differences. The first is the inline storage, which is a trailing objects array. The second is that being able to dynamically resize the operand list is optional. This means that we can enable the cases where operations need to change the number of operands after construction without losing the spatial locality benefits of the common case (operation instructions / non-control flow instructions with a lifetime fixed number of operands). PiperOrigin-RevId: 231910497
* Recommit: Define a AffineOps dialect as well as an AffineIfOp operation. ↵River Riddle2019-03-292-80/+51
| | | | | | Replace all instances of IfInst with AffineIfOp and delete IfInst. PiperOrigin-RevId: 231342063
* Automated rollback of changelist 231318632.Nicolas Vasilache2019-03-292-51/+80
| | | | PiperOrigin-RevId: 231327161
* Define a AffineOps dialect as well as an AffineIfOp operation. Replace all ↵River Riddle2019-03-292-80/+51
| | | | | | instances of IfInst with AffineIfOp and delete IfInst. PiperOrigin-RevId: 231318632
* Change the ForInst induction variable to be a block argument of the body ↵River Riddle2019-03-291-2/+3
| | | | | | instead of the ForInst itself. This is a necessary step in converting ForInst into an operation. PiperOrigin-RevId: 231064139
* Drop AffineMap::Null and IntegerSet::NullNicolas Vasilache2019-03-291-160/+158
| | | | | | | | | | | | | | | | | | | | Addresses b/122486036 This CL addresses some leftover crumbs in AffineMap and IntegerSet by removing the Null method and cleaning up the constructors. As the ::Null uses were tracked down, opportunities appeared to untangle some of the Parsing logic and make it explicit where AffineMap/IntegerSet have ambiguous syntax. Previously, ambiguous cases were hidden behind the implicit pointer values of AffineMap* and IntegerSet* that were passed as function parameters. Depending the values of those pointers one of 3 behaviors could occur. This parsing logic convolution is one of the rare cases where I would advocate for code duplication. The more proper fix would be to make the syntax unambiguous or to allow some lookahead. PiperOrigin-RevId: 231058512
* Allow operations to hold a blocklist and add support for parsing/printing a ↵River Riddle2019-03-291-36/+99
| | | | | | block list for verbose printing. PiperOrigin-RevId: 230951462
* Migrate VectorOrTensorType/MemRefType shape api to use int64_t instead of int.River Riddle2019-03-291-18/+20
| | | | PiperOrigin-RevId: 230605756
* Add asmparser/printer support for locations to make them round-trippable. ↵River Riddle2019-03-292-5/+215
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Location printing is currently behind a command line flag "mlir-print-debuginfo", we can rethink this when we have a pass for stripping debug info or when we have support for printer flags. Example inline notation: trailing-location ::= 'loc' '(' location ')' // FileLineCol Location. %1 = "foo"() : () -> i1 loc("mysource.cc":10:8) // Name Location return loc("foo") // CallSite Location return loc(callsite("foo" at "mysource.cc":19:9)) // Fused Location /// Without metadata func @inline_notation() loc(fused["foo", "mysource.cc":10:8]) /// With metadata return loc(fused<"myPass">["foo", "foo2"]) // Unknown location. return loc(unknown) Locations are currently only printed with inline notation at the line of each instruction. Further work is needed to allow for reference notation, e.g: ... return loc 1 } ... loc 1 = "source.cc":10:1 PiperOrigin-RevId: 230587621
* Unify terms regarding assembly form to use generic vs. customLei Zhang2019-03-291-4/+4
| | | | | | | | | | | | This CL just changes various docs and comments to use the term "generic" and "custom" when mentioning assembly forms. To be consist, several methods are also renamed: * FunctionParser::parseVerboseOperation() -> parseGenericOperation() * ModuleState::hasShorthandForm() -> hasCustomForm() * OpAsmPrinter::printDefaultOp() -> printGenericOp() PiperOrigin-RevId: 230568819
* Add a constant folding hook to ExtractElementOp to fold extracting the ↵River Riddle2019-03-291-1/+1
| | | | | | element of a constant. This also adds a 'getValue' function to DenseElementsAttr and SparseElementsAttr to get the element at a constant index. PiperOrigin-RevId: 230098938
* [MLIR] Add functionality for constructing a DenseElementAttr from an array ↵River Riddle2019-03-291-35/+6
| | | | | | of attributes and rerwite DenseElementsAttr::writeBits/readBits to handle non uniform bitwidths. This fixes asan failures that happen when using non uniform bitwidths. PiperOrigin-RevId: 229815107
* Check that at least one constraint is parsed when parsing an IntegerSet.River Riddle2019-03-291-2/+9
| | | | PiperOrigin-RevId: 229248638
* Emit unsupported error when parsing a DenseElementAttr with an integer type ↵River Riddle2019-03-291-0/+6
| | | | | | | | of greater than 64 bits. DenseElementAttr currently does not support value bitwidths of > 64. This can result in asan failures and crashes when trying to invoke DenseElementsAttr::writeBits/DenseElementsAttr::readBits. PiperOrigin-RevId: 229241125
* Add missing return post parse failure for the indices of a sparse attribute.River Riddle2019-03-291-0/+2
| | | | PiperOrigin-RevId: 229231462
* Return an empty IntegerSet if the '(' is not parsed.River Riddle2019-03-291-2/+3
| | | | PiperOrigin-RevId: 229198934
* Add a FloatAttr::getChecked, and invoke it during Attribute parsing.River Riddle2019-03-291-2/+6
| | | | PiperOrigin-RevId: 229167099
* Add check for '[' when parsing a tensor literal list.River Riddle2019-03-291-1/+5
| | | | PiperOrigin-RevId: 228913908
* Follow up from previous change to avoid setting tokStart 2x.Jacques Pienaar2019-03-291-3/+1
| | | | PiperOrigin-RevId: 228903980
* Fix omitted return post failed parseJacques Pienaar2019-03-291-0/+2
| | | | PiperOrigin-RevId: 228903905
* Skip over whitespace using loop. NFC.Jacques Pienaar2019-03-291-7/+16
| | | | | | Else we can stack overflow on a long sequence of whitespace. PiperOrigin-RevId: 228893517
OpenPOWER on IntegriCloud