summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Parser
Commit message (Collapse)AuthorAgeFilesLines
...
* Enable arithmetics for index types.Alex Zinenko2019-03-291-2/+6
| | | | | | | | | | | | | | | | | | | | | | | Arithmetic and comparison instructions are necessary to implement, e.g., control flow when lowering MLFunctions to CFGFunctions. (While it is possible to replace some of the arithmetics by affine_apply instructions for loop bounds, it is still necessary for loop bounds checking, steps, if-conditions, non-trivial memref subscripts, etc.) Furthermore, working with indirect accesses in, e.g., lookup tables for large embeddings, may require operating on tensors of indexes. For example, the equivalents to C code "LUT[Index[i]]" or "ResultIndex[i] = i + j" where i, j are loop induction variables require the arithmetics on indices as well as the possibility to operate on tensors thereof. Allow arithmetic and comparison operations to apply to index types by declaring them integer-like. Allow tensors whose element type is index for indirection purposes. The absence of vectors with "index" element type is explicitly tested, but the only justification for this restriction in the CL introducing the test is "because we don't need them". Do NOT enable vectors of index types, although it makes vector and tensor types inconsistent with respect to allowed element types. PiperOrigin-RevId: 220614055
* Uniformize MemRefType well-formedness checks.Alex Zinenko2019-03-291-14/+2
| | | | | | | | | | | | | | | | | | | | | | | Introduce a new public static member function, MemRefType::getChecked, intended for the users that want detailed error messages to be emitted during MemRefType construction and can gracefully handle these errors. This function takes a Location of the "MemRef" token if known. The parser is one user of getChecked that has location information, it outputs errors as compiler diagnostics. Other users may pass in an instance of UnknownLoc and still have error messages emitted. Compiler-internal users not expecting the MemRefType construction to fail should call MemRefType::get, which now aborts on failure with a generic message. Both "getChecked" and "get" call to a static free function that does actual construction with well-formedness checks, optionally emits errors and returns nullptr on failure. The location information passed to getChecked has voluntarily coarse precision. The error messages are intended for compiler engineers and do not justify heavier API than a single location. The text of the messages can be written so that it pinpoints the actual location of the error within a MemRef declaration. PiperOrigin-RevId: 219765902
* Implement value type abstraction for types.River Riddle2019-03-291-89/+89
| | | | | | This is done by changing Type to be a POD interface around an underlying pointer storage and adding in-class support for isa/dyn_cast/cast. PiperOrigin-RevId: 219372163
* Perform the MemRef layout map dimensionality check in the Parser.Alex Zinenko2019-03-291-0/+8
| | | | | | | | | | | | | | | | | | | | | | | This check was being performed in AllocOp::verify. However it is not specific to AllocOp and should apply to all MemRef type declarations. At the same time, the unique *Type factory functions in MLIRContext do not have access to location information necessary to properly emit diagnostics. Emit the error in Parser where the location information is available. Keep the error emission in AllocOp for the cases of programmatically-constructed, e.g. through Builders, IR with a note. Once we decided on the diagnostic infrastructure in type construction system, the type-related checks should be removed from specific Ops. Correct several parser test cases that have been using affine maps of mismatching dimensionality. This CL prepares for an upcoming change that will drop trivial identity affine map compositions during MemRefType construction. In that case, the dimensionality mismatch error must be emitted before dropping the identity map, i.e. during the type construction at the latest and before "verify" being called. PiperOrigin-RevId: 218844127
* Introduce integer set attributeUday Bondhugula2019-03-291-32/+79
| | | | | | | - add IntegerSetAttr to Attributes; add parsing and other support for it (builder, etc.). PiperOrigin-RevId: 218804579
* Change sigil for integer set: @@ -> #Uday Bondhugula2019-03-294-99/+126
| | | | PiperOrigin-RevId: 218786684
* Implement value type abstraction for attributes.River Riddle2019-03-291-38/+37
| | | | | | This is done by changing Attribute to be a POD interface around an underlying pointer storage and adding in-class support for isa/dyn_cast/cast. PiperOrigin-RevId: 218764173
* Introduce Fourier-Motzkin variable elimination + other cleanup/supportUday Bondhugula2019-03-291-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Introduce Fourier-Motzkin variable elimination to eliminate a dimension from a system of linear equalities/inequalities. Update isEmpty to use this. Since FM is only exact on rational/real spaces, an emptiness check based on this is guaranteed to be exact whenever it says the underlying set is empty; if it says, it's not empty, there may still be no integer points in it. Also, supports a version that computes "dark shadows". - Test this by checking for "always false" conditionals in if statements. - Unique IntegerSet's that are small (few constraints, few variables). This basically means the canonical empty set and other small sets that are likely commonly used get uniqued; allows checking for the canonical empty set by pointer. IntegerSet::kUniquingThreshold gives the threshold constraint size for uniqui'ing. - rename simplify-affine-expr -> simplify-affine-structures Other cleanup - IntegerSet::numConstraints, AffineMap::numResults are no longer needed; remove them. - add copy assignment operators for AffineMap, IntegerSet. - rename Invalid() -> Null() on AffineExpr, AffineMap, IntegerSet - Misc cleanup for FlatAffineConstraints API PiperOrigin-RevId: 218690456
* Change typedef to using to be consistent across the codebaseLei Zhang2019-03-291-2/+2
| | | | | | Google C++ style guide also prefers using to typedef. PiperOrigin-RevId: 218541849
* Add support to opaque elements attributesFeng Liu2019-03-292-1/+22
| | | | | | | | | | | | | For some of the constant vector / tesor, if the compiler doesn't need to interpret their elements content, they can be stored in this class to save the serialize / deserialize cost. syntax: `opaque<` tensor-type `,` opaque-string `>` opaque-string ::= `0x` [0-9a-fA-F]* PiperOrigin-RevId: 218399426
* Replace the "OperationSet" abstraction with a new Dialect abstraction. This isChris Lattner2019-03-291-7/+2
| | | | | | | | | a step forward because now every AbstractOperation knows which Dialect it is associated with, enabling things in the future like "constant folding hooks" which will be important for layering. This is also a bit nicer on the registration side of things. PiperOrigin-RevId: 218104230
* Use APFloat for FloatAttributeFeng Liu2019-03-291-3/+3
| | | | | | | | | | | | We should be able to represent arbitrary precision Float-point values inside the IR, so compiler optimizations, such as constant folding can be done independently on the compiling platform. This CL also added a new field, AttrValueGetter, to the Attr class definition for TableGen. This field is used to customize which mlir::Attr getter method to get the defined PrimitiveType. PiperOrigin-RevId: 218034983
* Add support to constant sparse tensor / vector attributeFeng Liu2019-03-292-5/+107
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add support to constant dense vector/tensor attribute.Feng Liu2019-03-292-78/+278
| | | | | | | | | | | | | | | | | | | 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
* Fail if operation name contains null char.Jacques Pienaar2019-03-291-0/+2
| | | | | | | The null char is allowed in a string but not in an operation's name, so fail parsing in the latter case. PiperOrigin-RevId: 217138049
* Avoid leak when parsing fails and BasicBlock has no use/function.Jacques Pienaar2019-03-291-27/+74
| | | | | | | | | | | Associate BasicBlocks with the function being parsed to avoid leaks in the case of parse failures. Associating with the function means that we can no longer determine if defined/fwd declared simply by considering if a BasicBlock has an associated function, so track forward declared block references explicitly (this should also allow flagging multiple undeclared fwd references). Split out getting the named block from defining it, in the case of definition move the block to the end of the function. Also destroy all forward reference placeholders in FunctionParser. Return parse failure in parseAttributeDict if there is no left brace instead of asserting. PiperOrigin-RevId: 217049507
* Split BuiltinOps out of StandardOps.Jacques Pienaar2019-03-291-0/+1
| | | | | | | | * Move Return, Constant and AffineApply out into BuiltinOps; * BuiltinOps are always registered, while StandardOps follow the same dynamic registration; * Kept isValidX in MLValue as we don't have a verify on AffineMap so need to keep it callable from Parser (I wanted to move it to be called in verify instead); PiperOrigin-RevId: 216592527
* [MLIR] IntegerSet value typeNicolas Vasilache2019-03-291-15/+15
| | | | | | | | | | | | | | | This CL applies the same pattern as AffineMap to IntegerSet: a simple struct that acts as the storage is allocated in the bump pointer. The IntegerSet is immutable and accessed everywhere by value. Note that unlike AffineMap, it is not possible to remove the MLIRContext parameter when constructing an IntegerSet for now. One possible way to achieve this would be to add an enum to distinguish between the mathematically empty set, the universe set and other sets. This is left for future discussion. PiperOrigin-RevId: 216545361
* Add support to constant splat vector/tensor attribute.Feng Liu2019-03-292-0/+39
| | | | | | | | | 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
* Change the representation of an operation name to be either anChris Lattner2019-03-291-1/+1
| | | | | | | | | AbstractOperation* or an Identifier. This makes it possible to get to stuff in AbstractOperation faster than going through a hash table lookup. This makes constant folding a bit faster now, but will become more important with subsequent changes. PiperOrigin-RevId: 216476772
* Support `getShape`, `hasStaticShape` and `getDimSize` methods for all the ↵Feng Liu2019-03-291-2/+2
| | | | | | Vector and Tensor Types. PiperOrigin-RevId: 216447553
* [MLIR] AffineMap value typeNicolas Vasilache2019-03-291-26/+26
| | | | | | | | This CL applies the same pattern as AffineExpr to AffineMap: a simple struct that acts as the storage is allocated in the bump pointer. The AffineMap is immutable and accessed everywhere by value. PiperOrigin-RevId: 216445930
* Fix some leak and crash found via fuzzing.Jacques Pienaar2019-03-292-1/+9
| | | | | | Tried adding a fuzzer target (cl/216378253) and ran into a few problems, and fixing two of these. PiperOrigin-RevId: 216425403
* [MLIR] Sketch AffineExpr value typeNicolas Vasilache2019-03-291-14/+12
| | | | | | | | | | | | | | | | This CL sketches what it takes for AffineExpr to fully have by-value semantics and not be a not-so-smart pointer anymore. This essentially makes the underyling class a simple storage struct and implements the operations on the value type directly. Since there is no forwarding of operations anymore, we can full isolate the storage class and make a hard visibility barrier by moving detail::AffineExpr into AffineExprDetail.h. AffineExprDetail.h is only included where storage-related information is needed. PiperOrigin-RevId: 216385459
* [MLIR] AffineExpr final cleanupsNicolas Vasilache2019-03-291-51/+47
| | | | | | | | | | | This CL: 1. performs the global codemod AffineXExpr->AffineXExprClass and AffineXExprRef -> AffineXExpr; 2. simplifies function calls by removing the redundant MLIRContext parameter; 3. adds missing binary operator versions of scalar op AffineExpr where it makes sense. PiperOrigin-RevId: 216242674
* [MLIR] Cleanup AffineExprNicolas Vasilache2019-03-291-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | This CL introduces a series of cleanups for AffineExpr value types: 1. to make it clear that the value types should be used, the pointer AffineExpr types are put in the detail namespace. Unfortunately, since the value type operator-> only forwards to the underlying pointer type, we still need to expose this in the include file for now; 2. AffineExprKind is ok to use, it thus comes out of detail and thus of AffineExpr 3. getAffineDimExpr, getAffineSymbolExpr, getAffineConstantExpr are similarly extracted as free functions and their naming is mande consistent across Builder, MLContext and AffineExpr 4. AffineBinaryOpEx::simplify functions are made into static free functions. In particular it is moved away from AffineMap.cpp where it does not belong 5. operator AffineExprType is made explicit 6. uses the binary operators everywhere possible 7. drops the pointer usage everywhere outside of AffineExpr.cpp, MLIRContext.cpp and AsmPrinter.cpp PiperOrigin-RevId: 216207212
* [MLIR] Value types for AffineXXXExprNicolas Vasilache2019-03-291-51/+52
| | | | | | | | | | | | | | | | | | | | | This CL makes AffineExprRef into a value type. Notably: 1. drops llvm isa, cast, dyn_cast on pointer type and uses member functions on the value type. It may be possible to still use classof (in a followup CL) 2. AffineBaseExprRef aggressively casts constness away: if we mean the type is immutable then let's jump in with both feet; 3. Drop implicit casts to the underlying pointer type because that always results in surprising behavior and is not needed in practice once enough cleanup has been applied. The remaining negative I see is that we still need to mix operator. and operator->. There is an ugly solution that forwards the methods but that ends up duplicating the class hierarchy which I tried to avoid as much as possible. But maybe it's not that bad anymore since AffineExpr.h would still contain a single class hierarchy (the duplication would be impl detail in.cpp) PiperOrigin-RevId: 216188003
* Rename affineint type to index type. The name 'index' may not be perfect, ↵Chris Lattner2019-03-292-13/+13
| | | | | | | | | | | | | | 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
* [RFC][MLIR] Use AffineExprRef in place of AffineExpr* in IRNicolas Vasilache2019-03-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL starts by replacing AffineExpr* with value-type AffineExprRef in a few places in the IR. By a domino effect that is pretty telling of the inconsistencies in the codebase, const is removed where it makes sense. The rationale is that the decision was concisously made that unique'd types have pointer semantics without const specifier. This is fine but we should be consistent. In the end, the only logical invariant is that there should never be such a thing as a const AffineExpr*, const AffineMap* or const IntegerSet* in our codebase. This CL takes a number of shortcuts to killing const with fire, in particular forcing const AffineExprRef to return the underlying non-const AffineExpr*. This will be removed once AffineExpr* has disappeared in containers but for now such shortcuts allow a bit of sanity in this long quest for cleanups. The **only** places where const AffineExpr*, const AffineMap* or const IntegerSet* may still appear is by transitive needs from containers, comparison operators etc. There is still one major thing remaining here: figure out why cast/dyn_cast return me a const AffineXXX*, which in turn requires a bunch of ugly const_casts. I suspect this is due to the classof taking const AffineXXXExpr*. I wonder whether this is a side effect of 1., if it is coming from llvm itself (I'd doubt it) or something else (clattner@?) In light of this, the whole discussion about const makes total sense to me now and I would systematically apply the rule that in the end, we should never have any const XXX in our codebase for unique'd types (assuming we can remove them all in containers and no additional constness constraint is added on us from the outside world). PiperOrigin-RevId: 215811554
* [MLIR] Remove uses of AffineExpr* outside of IRNicolas Vasilache2019-03-291-3/+3
| | | | | | | | | | | | | This CL uniformizes the uses of AffineExprWrap outside of IR. The public API of AffineExpr builder is modified to only use AffineExprWrap. A few places access AffineExprWrap.expr, this is only while the API is in transition to easily keep track (i.e. make expr private and let the compiler track the errors). Parser.cpp exhibits patterns that are dependent on nullptr values so converting it is left for another CL. PiperOrigin-RevId: 215642005
* Change loop step to be a positive integral constantUday Bondhugula2019-03-291-0/+7
| | | | | | Changing this per discussion on mlir-team. Spec updated. PiperOrigin-RevId: 214868483
* Add support to TF f32_ref type in MLIRFeng Liu2019-03-291-0/+1
| | | | PiperOrigin-RevId: 214722005
* Supports TF Complex64/Complex128 types in the tf/mlir roundtrip pass.Feng Liu2019-03-292-0/+8
| | | | | | | | Alternatively, we can defined a TFComplexType with a width parameter in the mlir, then both types can be converted to the same mlir type with different width (like IntegerType). We chose to use a direct mapping because there are only two TF Complex types. PiperOrigin-RevId: 213856651
* Support TF Variant type in the tf/mlir roundtrip pass.Feng Liu2019-03-292-2/+5
| | | | PiperOrigin-RevId: 213748573
* Handle the TF resource data type in the TF/XLA roundtrip pass.Feng Liu2019-03-292-0/+4
| | | | PiperOrigin-RevId: 213650346
* Add function attributes for ExtFunction, CFGFunction and MLFunction.Feng Liu2019-03-292-6/+43
| | | | PiperOrigin-RevId: 213540509
* Change unranked tensor syntax from tensor<??f32> to tensor<*xf32> perChris Lattner2019-03-293-18/+27
| | | | | | discussion on the list. PiperOrigin-RevId: 212838226
* Introduce pretty syntax for shape_cast as discussed on the list last week.Chris Lattner2019-03-291-0/+8
| | | | PiperOrigin-RevId: 212823681
* Add misc builder convenience methods for AffineMap's, for statement's.Uday Bondhugula2019-03-291-1/+1
| | | | | | | Use these methods to simplify existing code. Rename getConstantMap getConstantAffineMap. Move declarations to group similar ones together. PiperOrigin-RevId: 212814829
* Extend getConstantTripCount to deal with a larger subset of loop bounds; ↵Uday Bondhugula2019-03-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | make loop unroll/unroll-and-jam more powerful; add additional affine expr builder methods - use previously added analysis/simplification to infer multiple of unroll factor trip counts, making loop unroll/unroll-and-jam more general. - for loop unroll, support bounds that are single result affine map's with the same set of operands. For unknown loop bounds, loop unroll will now work as long as trip count can be determined to be a multiple of unroll factor. - extend getConstantTripCount to deal with single result affine map's with the same operands. move it to mlir/Analysis/LoopAnalysis.cpp - add additional builder utility methods for affine expr arithmetic (difference, mod/floordiv/ceildiv w.r.t postitive constant). simplify code to use the utility methods. - move affine analysis routines to AffineAnalysis.cpp/.h from AffineStructures.cpp/.h. - Rename LoopUnrollJam to LoopUnrollAndJam to match class name. - add an additional simplification for simplifyFloorDiv, simplifyCeilDiv - Rename AffineMap::getNumOperands() getNumInputs: an affine map by itself does not have operands. Operands are passed to it through affine_apply, from loop bounds/if condition's, etc., operands are stored in the latter. This should be sufficiently powerful for now as far as unroll/unroll-and-jam go for TPU code generation, and can move to other analyses/transformations. Loop nests like these are now unrolled without any cleanup loop being generated. for %i = 1 to 100 { // unroll factor 4: no cleanup loop will be generated. for %j = (d0) -> (d0) (%i) to (d0) -> (5*d0 + 3) (%i) { %x = "foo"(%j) : (affineint) -> i32 } } for %i = 1 to 100 { // unroll factor 4: no cleanup loop will be generated. for %j = (d0) -> (d0) (%i) to (d0) -> (d0 - d mod 4 - 1) (%i) { %y = "foo"(%j) : (affineint) -> i32 } } for %i = 1 to 100 { for %j = (d0) -> (d0) (%i) to (d0) -> (d0 + 128) (%i) { %x = "foo"() : () -> i32 } } TODO(bondhugula): extend this to LoopUnrollAndJam as well in the next CL (with minor changes). PiperOrigin-RevId: 212661212
* Update error message for invalid operand token while parsing operand list.Jacques Pienaar2019-03-291-3/+1
| | | | | | Previously the error could mislead into thinking it was a parser bug instead of the input being erroneous. Update to make it clearer. PiperOrigin-RevId: 212271145
* rework the custom op verifier hooks to use the diagnostic emissionChris Lattner2019-03-291-2/+2
| | | | | | | | | | infrastructure, instead of returning a const char*. This allows custom formatting and more interesting diagnostics. This patch regresses the error message quality from the control flow lowering pass, I'll address this in a subsequent patch. PiperOrigin-RevId: 212210681
* Check for absence of delimiters when delimiters is None and fixed number of ↵Jacques Pienaar2019-03-291-1/+14
| | | | | | | | operands expected. Ensure delimiters are absent where not expected. This is only checked in the case where operand count is known. This allows for the currently accepted case where there is a operand list with no delimiter and variable number of operands (which could be empty), followed by a delimited operand list. PiperOrigin-RevId: 212202064
* Return error status when number of operands don't match while parsing.Jacques Pienaar2019-03-291-2/+2
| | | | | | Previously an error would be emitted but parsing would continue as false was being returned. PiperOrigin-RevId: 212192167
* Change SourgeMgr to const reference in Parser/Lexer.Jacques Pienaar2019-03-293-14/+15
| | | | | | SourceMgr is not be mutated during parsing/lexing. PiperOrigin-RevId: 212145759
* Add location specifier to MLIR Functions, and:Chris Lattner2019-03-291-28/+17
| | | | | | | | | | | - Compress the identifier/kind of a Function into a single word. - Eliminate otherFailure from verifier now that we always have a location - Eliminate the error string from the verifier now that we always have locations. - Simplify the parser's handling of fn forward references, using the location tracked by the function. PiperOrigin-RevId: 211985101
* Add parseSourceString method to make it easy for clients to parse a string ↵Jacques Pienaar2019-03-291-0/+16
| | | | | | to a module. PiperOrigin-RevId: 211354628
* Continue revising diagnostic handling to simplify and generalize it, and ↵Chris Lattner2019-03-293-101/+49
| | | | | | | | | | | | | | | | | | | improve related infra. - Add a new -verify mode to the mlir-opt tool that allows writing test cases for optimization and other passes that produce diagnostics. - Refactor existing the -check-parser-errors flag to mlir-opt into a new -split-input-file option which is orthogonal to -verify. - Eliminate the special error hook the parser maintained and use the standard MLIRContext's one instead. - Enhance the default MLIRContext error reporter to print file/line/col of errors when it is available. - Add new createChecked() methods to the builder that create ops and invoke the verify hook on them, use this to detected unhandled code in the RaiseControlFlow pass. - Teach mlir-opt about expected-error @+, it previously only worked with @- PiperOrigin-RevId: 211305770
* Implement operands for the 'if' statement.Tatiana Shpeisman2019-03-291-25/+23
| | | | | | | | This CL also includes two other minor changes: - change the implemented syntax from 'if (cond)' to 'if cond', as specified by MLIR spec. - a minor fix to the implementation of the ForStmt. PiperOrigin-RevId: 210618122
* Introduce a new Location abstraction to represent location data in a structuredChris Lattner2019-03-291-20/+37
| | | | | | | | (and more useful) way rather than hacking up a pile of attributes for it. In the future this will grow to represent inlined locations, fusion cases etc, but for now we start with simple Unknown and File/Line/Col locations. NFC. PiperOrigin-RevId: 210485775
OpenPOWER on IntegriCloud