summaryrefslogtreecommitdiffstats
path: root/mlir/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
...
* Per review on the previous CL, drop MLFuncBuilder::createOperation, changingChris Lattner2019-03-291-12/+0
| | | | | | | | clients to use OperationState instead. This makes MLFuncBuilder more similiar to CFGFuncBuilder. This whole area will get tidied up more when cfg and ml worlds get unified. This patch is just gardening, NFC. PiperOrigin-RevId: 226701959
* Give StmtBlocks a use-def list, and give OperationStmt's the ability to haveChris Lattner2019-03-292-23/+118
| | | | | | | | | optional successor operands when they are terminator operations. This isn't used yet, but is part 2/n towards merging BasicBlock into StmtBlock and Instruction into OperationStmt. PiperOrigin-RevId: 226684636
* Refactor ForStmt: having it contain a StmtBlock instead of subclassingChris Lattner2019-03-294-9/+10
| | | | | | | | | | | | | | StmtBlock. This is more consistent with IfStmt and also conceptually makes more sense - a forstmt "isn't" its body, it contains its body. This is step 1/N towards merging BasicBlock and StmtBlock. This is required because in the new regime StmtBlock will have a use list (just like BasicBlock does) of operands, and ForStmt already has a use list for its induction variable. This is a mechanical patch, NFC. PiperOrigin-RevId: 226684158
* Unify type uniquing and construction.River Riddle2019-03-293-353/+257
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows for us to decouple type uniquing/construction from MLIRContext and pave the way for dialect specific types. To accomplish this we two new classes, TypeUniquer and TypeStorageAllocator. * TypeUniquer is now responsible for all construction and uniquing of types. * TypeStorageAllocator is a utility used by derived type storage objects to allocate memory within an MLIRContext. This cl also standardizes what a derived type storage class needs to provide: - Define a type alias, KeyTy, to a type that uniquely identifies the instance of the type within its kind. * The key type must be constructible from the values passed into the detail::TypeUniquer::get call after the type kind. * The key type must have a llvm::DenseMapInfo specialization for hashing. - Provide a method, 'KeyTy getKey() const', to construct the key type from an existing storage instance. - Provide a construction method: 'DerivedStorage *construct(TypeStorageAllocator &, ...)' that builds a unique instance of the derived storage. The arguments after the TypeStorageAllocator must correspond with the values passed into the detail::TypeUniquer::get call after the type kind. PiperOrigin-RevId: 226507184
* Densify storage for f16, f32 and support f16 semantics in FloatAttrsAlex Zinenko2019-03-293-39/+65
| | | | | | | | | | | | | | | | | | Existing implementation always uses 64 bits to store floating point values in DenseElementsAttr. This was due to FloatAttrs always a `double` for storage independently of the actual type. Recent commits added support for FloatAttrs with the proper f32 type and floating semantics and changed the bitwidth reporting on FloatType. Use the existing infrastructure for densely storing 16 and 32-bit values in DenseElementsAttr storage to store f16 and f32 values. Move floating semantics definition to the FloatType level. Properly support f16 / IEEEhalf semantics at the FloatAttr level and in the builder. Note that bf16 is still stored as a 64-bit value with IEEEdouble semantics because APFloat does not have first-class support for bf16 types. PiperOrigin-RevId: 225981289
* Type system: replace Type::getBitWidth with getIntOrFloatBitWidthAlex Zinenko2019-03-295-29/+60
| | | | | | | | | | | | | | | | | | | | | | | As MLIR moves towards dialect-specific types, a generic Type::getBitWidth does not make sense for all of them. Even with the current type system, the bit width is not defined (and causes the method in question to abort) for all TensorFlow types. This commit restricts the bit width definition to primitive standard types that have a number of bits appearing verbatim in their type, i.e., integers and floats. As a side effect, it delegates the decision on the bit width of the `index` to the backends. Existing backends currently hardcode it to 64 bits. The Type::getBitWidth method is replaced by Type::getIntOrFloatBitWidth that only applies to integers and floats. The call sites are updated to use the new method, where applicable, or rewritten so as not rely on it. Incidentally, this fixes a utility method that did not account for memrefs being allowed to have vectors as element types in the size computation. As an observation, several places in the code use Type in places where a more specific type could be used instead. Some of those are fixed by this commit. PiperOrigin-RevId: 225844792
* Fix builder getFloatAttr of double to use F64 type and use fltSemantics in ↵Jacques Pienaar2019-03-293-3/+54
| | | | | | | | | | | | FloatAttr. Store FloatAttr using more appropriate fltSemantics (mostly fixing up F32/F64 storage, F16/BF16 pending). Previously F32 type was used incorrectly for double (the storage was double). Also add query method that returns fltSemantics for IEEE fp types and use that to verify that the APfloat given matches the type: * FloatAttr created using APFloat is verified that the semantics of the type and APFloat matches; * FloatAttr created using double has the APFloat created to match the semantics of the type; Change parsing of tensor negative splat element to pass in the element type expected. Misc other changes to account for the storage type matching the attribute. PiperOrigin-RevId: 225821834
* Disallow index types as elements of vector, memref and tensor typesAlex Zinenko2019-03-291-1/+2
| | | | | | | | | | | | | | | | | An extensive discussion demonstrated that it is difficult to support `index` types as elements of compound (vector, memref, tensor) types. In particular, their size is unknown until the target-specific lowering takes place. MLIR may need to store constants of the fixed-shape compound types (e.g., vector<4 x index>) internally and must know the size of the element type and data layout constraints. The same information is necessary for target-specific lowering and translation to reliably support compound types with `index` elements, but MLIR does not have a dedicated target description mechanism yet. The uses cases for compound types with `index` elements, should they appear, can be handled via an `index_cast` operation that converts between `index` and fixed-size integer types at the SSA value level instead of the type level. PiperOrigin-RevId: 225064373
* Return bool from all emitError methods similar to Operation::emitOpErrorSmit Hinsu2019-03-296-51/+39
| | | | | | | | | | | | | This simplifies call-sites returning true after emitting an error. After the conversion, dropped braces around single statement blocks as that seems more common. Also, switched to emitError method instead of emitting Error kind using the emitDiagnostic method. TESTED with existing unit tests PiperOrigin-RevId: 224527868
* [MLIR] Add AffineMap composition and use it in MaterializationNicolas Vasilache2019-03-291-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL adds the following free functions: ``` /// Returns the AffineExpr e o m. AffineExpr compose(AffineExpr e, AffineMap m); /// Returns the AffineExpr f o g. AffineMap compose(AffineMap f, AffineMap g); ``` This addresses the issue that AffineMap composition is only available at a distance via AffineValueMap and is thus unusable on Attributes. This CL thus implements AffineMap composition in a more modular and composable way. This CL does not claim that it can be a good replacement for the implementation in AffineValueMap, in particular it does not support bounded maps atm. Standalone tests are added that replicate some of the logic of the AffineMap composition pass. Lastly, affine map composition is used properly inside MaterializeVectors and a standalone test is added that requires permutation_map composition with a projection map. PiperOrigin-RevId: 224376870
* Complete multiple unhandled cases for DmaGeneration / getMemRefRegion;Uday Bondhugula2019-03-291-0/+8
| | | | | | | | | | | | | | | | | | | update/improve/clean up API. - update FlatAffineConstraints::getConstBoundDifference; return constant differences between symbolic affine expressions, look at equalities as well. - fix buffer size computation when generating DMAs symbolic in outer loops, correctly handle symbols at various places (affine access maps, loop bounds, loop IVs outer to the depth at which DMA generation is being done) - bug fixes / complete some TODOs for getMemRefRegion - refactor common code b/w memref dependence check and getMemRefRegion - FlatAffineConstraints API update; added methods employ trivial checks / detection - sufficient to handle hyper-rectangular cases in a precise way while being fast / low complexity. Hyper-rectangular cases fall out as trivial cases for these methods while other cases still do not cause failure (either return conservative or return failure that is handled by the caller). PiperOrigin-RevId: 224229879
* Add isIntOrIndex() and isIntOrIndexOrFloat() into TypeLei Zhang2019-03-291-12/+4
| | | | | | | | | The checks for `isa<IndexType>() || isa<IntegerType>()` and `isa<IndexType>() || isa<IntegerType>() || isa<FloatType>()` are frequently used, so it's useful to have some helper methods for them. PiperOrigin-RevId: 224133596
* Fix two more getHashValues.Jacques Pienaar2019-03-291-2/+10
| | | | | | These were still returning the hash of the pointers resulting in the two getHashValues being different. PiperOrigin-RevId: 223862743
* Update getHashValue for ptr values stored in a DenseMap/Set to use ↵Jacques Pienaar2019-03-291-10/+41
| | | | | | | | getHasValue of KeyTy. Ensures both hash values returned are the same. Tested by triggering resize of map/set and verifying failure before change. PiperOrigin-RevId: 223651443
* RankedTensorType: Use getHashValue(KeyTy) when calling ↵Jacques Pienaar2019-03-291-1/+4
| | | | | | getHashValue(RankedTensorTypeStorage*). PiperOrigin-RevId: 223649958
* Avoid failing when attempting to print null Attribute.Jacques Pienaar2019-03-291-0/+5
| | | | | | This avoids segfaulting when dumping during debugging of failures. PiperOrigin-RevId: 223449494
* Split "rewrite" functionality out of Pattern into a new RewritePattern derivedChris Lattner2019-03-291-7/+10
| | | | | | | | class. This change is NFC, but allows for new kinds of patterns, specifically LegalizationPatterns which will be allowed to change the types of things they rewrite. PiperOrigin-RevId: 223243783
* Verify CmpIOp's result type to be bool-likeLei Zhang2019-03-293-2/+60
| | | | | | | | | This CL added two new traits, SameOperandsAndResultShape and ResultsAreBoolLike, and changed CmpIOp to embody these two traits. As a consequence, CmpIOp's result type now is verified to be bool-like. PiperOrigin-RevId: 223208438
* Add support for setting the location of an IROperandOwner.River Riddle2019-03-291-0/+8
| | | | PiperOrigin-RevId: 222995814
* Tidy up the replaceOp hooks in PatternMatch, generalizing them to support anyChris Lattner2019-03-291-24/+19
| | | | | | number of result ops. Among other things, this results in shorter names PiperOrigin-RevId: 222685039
* Minimal patch to allow patterns to rewrite multi-result instructions, ↵Chris Lattner2019-03-291-0/+23
| | | | | | related to b/119877155 PiperOrigin-RevId: 222597798
* Clean up parse_headers in mlirMLIR Team2019-03-291-0/+5
| | | | | | | | | Not having self-contained headers in LLVM is a constant pain. Don't make the same mistake in mlir. The only interesting change here is moving setSuccessor to Instructions.cpp, which breaks the cycle between Instructions.h and BasicBlock.h. PiperOrigin-RevId: 222440816
* Add verifier check for integer constants to check that the value can fit ↵River Riddle2019-03-291-1/+12
| | | | | | within the type bit width. PiperOrigin-RevId: 222335526
* Adds ConstantFoldHook registry in MLIRContextFeng Liu2019-03-293-5/+41
| | | | | | | | | | | | | | This reverts the previous method which needs to create a new dialect with the constant fold hook from TensorFlow. This new method uses a function object in dialect to store the constant fold hook. Once a hook is registered to the dialect, this function object will be assigned when the dialect is added to the MLIRContext. For the operations which are not registered, a new method getRegisteredDialects is added to the MLIRContext to query the dialects which matches their op name prefixes. PiperOrigin-RevId: 222310149
* Add functionality for erasing terminator successor operands and basic block ↵River Riddle2019-03-294-0/+43
| | | | | | arguments. PiperOrigin-RevId: 222303233
* Add support for getting the operand number from an ↵River Riddle2019-03-292-0/+19
| | | | | | IROperandImpl(InstOperand, BasicBlockOperand, StmtOperand). PiperOrigin-RevId: 222274598
* Add support for Operation::moveBefore(Operation *).River Riddle2019-03-291-0/+7
| | | | PiperOrigin-RevId: 222252521
* Change pretty printing of constant so that the attributes precede the value.Jacques Pienaar2019-03-291-3/+6
| | | | | | | | This does create an inconsistency between the print formats (e.g., attributes are normally before operands) but fixes an invalid parsing & keeps constant uniform wrt itself (function or int attributes have type at same place). And specifying the specific type for a int/float attribute might get revised shortly. Also add test to verify that output printed can be parsed again. PiperOrigin-RevId: 221923893
* [MLIR] Rename OperationInst to Instruction.River Riddle2019-03-293-8/+8
| | | | PiperOrigin-RevId: 221795407
* Merge OperationInst functionality into Instruction.River Riddle2019-03-294-161/+112
| | | | | | We do some limited renaming here but define an alias for OperationInst so that a follow up cl can solely perform the large scale renaming. PiperOrigin-RevId: 221726963
* Add Type to int/float attributes.Jacques Pienaar2019-03-297-45/+101
| | | | | | | | | | | | * Optionally attach the type of integer and floating point attributes to the attributes, this allows restricting a int/float to specific width. - Currently this allows suffixing int/float constant with type [this might be revised in future]. - Default to i64 and f32 if not specified. * For index types the APInt width used is 64. * Change callers to request a specific attribute type. * Store iN type with APInt of width N. * This change does not handle the folding of constants of different types (e.g., doing int type promotions to support constant folding i3 and i32), and instead restricts the constant folding to only operate on the same types. PiperOrigin-RevId: 221722699
* [MLIR] Merge terminator and uses into BasicBlock operations list handling.River Riddle2019-03-296-56/+15
| | | | PiperOrigin-RevId: 221700132
* Replace TerminatorInst with builtin terminator operations.River Riddle2019-03-296-199/+35
| | | | | Note: Terminators will be merged into the operations list in a follow up patch. PiperOrigin-RevId: 221670037
* Fix variables only used in assertions.River Riddle2019-03-292-2/+3
| | | | PiperOrigin-RevId: 221660580
* Add functionality for parsing/managing operation terminator successors.River Riddle2019-03-295-39/+327
| | | | | | Follow up patches will work to remove TerminatorInst. PiperOrigin-RevId: 221640621
* Fix hasStaticShape() method on vectors and tensors to work correctly for ↵Tatiana Shpeisman2019-03-291-3/+3
| | | | | | | | unranked tensors and remove getShape() method for unranked tensors. Unranked tensors used to return an empty list of dimensions as their shape. This is confusing since an empty list of dimensions is also returned for 0-D tensors. In particular, hasStaticShape() method used to check if any of the dimensions are -1, which held for unranked tensors even though they don't have static shape. PiperOrigin-RevId: 221571138
* ConvertToCFG: properly remap nested function attributes.Alex Zinenko2019-03-291-0/+33
| | | | | | | | | | | | Array attributes can nested and function attributes can appear anywhere at that level. They should be remapped to point to the generated CFGFunction after ML-to-CFG conversion, similarly to plain function attributes. Extract the nested attribute remapping functionality from the Parser to Utils. Extract out the remapping function for individual Functions from the module remapping function. Use these new functions in the ML-to-CFG conversion pass and in the parser. PiperOrigin-RevId: 221510997
* Start the plumbing for removing TerminatorInst.River Riddle2019-03-292-27/+102
| | | | | | | | | | * Add skeleton br/cond_br builtin ops. * Add a terminator trait for operations. * Mark ReturnOp as a Terminator. The functionality for managing/parsing/verifying successors will be added in a follow up cl. PiperOrigin-RevId: 221283000
* Optionally emit errors from IntegerType factory functions.Alex Zinenko2019-03-291-3/+22
| | | | | | | | | | | | | | | Similarly to other types, introduce "get" and "getChecked" static member functions for IntegerType. The latter emits errors to the error handler registered with the MLIR context and returns a null type for the caller to handle errors gracefully. This deduplicates type consistency checks between the parser and the builder. Update the parser to call IntegerType::getChecked for error reporting instead of the builder that would simply assert. This CL completes the type system error emission refactoring: the parser now only emits syntax-related errors for types while type factory systems may emit type consistency errors. PiperOrigin-RevId: 221165207
* Homogenize branch instruction arguments.Alex Zinenko2019-03-291-30/+24
| | | | | | | | | | | | | | | | | | | | | | | | | Branch instruction arguments were defined and used inconsistently across different instructions, in both the spec and the implementation. In particular, conditional and unconditional branch instructions were using different syntax in the implementation. This led to the IR we produce not being accepted by the parser. Update the printer to use common syntax: `(` list-of-SSA-uses `:` list-of-types `)`. The motivation for choosing this syntax as opposed to the one in the spec, `(` list-of-SSA-uses `)` `:` list-of-types is double-fold. First, it is tricky to differentiate the label of the false branch from the type while parsing conditional branches (which is what apparently motivated the implementation to diverge from the spec in the first place). Second, the ongoing convergence between terminator instructions and other operations prompts for consistency between their operand list syntax. After this change, the only remaining difference between the two is the use of parentheses. Update the comment of the parser that did not correspond to the code. Remove the unused isParenthesized argument from parseSSAUseAndTypeList. Update the spec accordingly. Note that the examples in the spec were _not_ using the EBNF defined a couple of lines above them, but were using the current syntax. Add a supplementary example of a branch to a basic block with multiple arguments. PiperOrigin-RevId: 221162655
* Switch IntegerAttr to use APInt.Jacques Pienaar2019-03-294-17/+63
| | | | | | | | Change the storage type to APInt from int64_t for IntegerAttr (following the change to APFloat storage in FloatAttr). Effectively a direct change from int64_t to 64-bit APInt throughout (the bitwidth hardcoded). This change also adds a getInt convenience method to IntegerAttr and replaces previous getValue calls with getInt calls. While this changes updates the storage type, it does not update all constant folding calls. PiperOrigin-RevId: 221082788
* - Simplify PatternMatch to *require* static benefits at pattern constructionChris Lattner2019-03-291-55/+13
| | | | | | | | | | | time. The "Fast and Flexible Instruction Selection With Constraints" paper from CC2018 makes a credible argument that dynamic costs aren't actually necessary/important, and we are not using them. - Check in my "MLIR Generic DAG Rewriter Infrastructure" design doc into the source tree. PiperOrigin-RevId: 221017546
* Falls back to dialect constant folding hookFeng Liu2019-03-292-4/+11
| | | | PiperOrigin-RevId: 220861133
* - Add support for fused locations.River Riddle2019-03-295-3/+157
| | | | | | | | | | | | | | | | | | | | | | These are locations that form a collection of other source locations with an optional metadata attribute. - Add initial support for print/dump for locations. Location Printing Examples: * Unknown : [unknown-location] * FileLineColLoc : third_party/llvm/llvm/projects/google-mlir/test/TensorFlowLite/legalize.mlir:6:8 * FusedLoc : <"tfl-legalize">[third_party/llvm/llvm/projects/google-mlir/test/TensorFlowLite/legalize.mlir:6:8, third_party/llvm/llvm/projects/google-mlir/test/TensorFlowLite/legalize.mlir:7:8] - Add diagnostic support for fused locs. * Prints the first location as the main location and the remaining as "fused from here" notes: e.g. third_party/llvm/llvm/projects/google-mlir/test/TensorFlowLite/legalize.mlir:6:8: error: This is an error. %1 = "tf.add"(%arg0, %0) : (i32, i32) -> i32 ^ third_party/llvm/llvm/projects/google-mlir/test/TensorFlowLite/legalize.mlir:7:8: error: Fused from here. %2 = "tf.relu"(%1) : (i32) -> i32 ^ PiperOrigin-RevId: 220835552
* Clean up TensorType construction.Alex Zinenko2019-03-291-8/+62
| | | | | | | | | | | | This CL introduces the following related changes: - move tensor element type validity checking to a static member function TensorType::isValidElementType - introduce get/getChecked similarly to MemRefType, where the checked function emits errors and returns nullptrs; - remove duplicate element type validity checking from the parser and rely on the type constructor to emit errors instead. PiperOrigin-RevId: 220694831
* Clean up VectorType construction.Alex Zinenko2019-03-291-10/+45
| | | | | | | | | | | | This CL introduces the following related changes: - factor out element type validity checking to a static member function VectorType::isValidElementType; - introduce get/getChecked similarly to MemRefType, where the checked function emits errors and returns nullptrs; - remove duplicate element type validity checking from the parser and rely on the type constructor to emit errors instead. PiperOrigin-RevId: 220693828
* Implement value type abstraction for locations.River Riddle2019-03-299-51/+141
| | | | | | Value type abstraction for locations differ from others in that a Location can NOT be null. NOTE: dyn_cast returns an Optional<T>. PiperOrigin-RevId: 220682078
* Allow vector types to have index elements.Alex Zinenko2019-03-291-1/+2
| | | | | | | | | | It is unclear why vector types were not allowed to have "index" as element type. Index values are integers, although of unknown bit width, and should behave as such. Vectors of integers are allowed and so are tensors of indices (for indirection purposes), it is more consistent to also have vectors of indices. PiperOrigin-RevId: 220630123
* Enable arithmetics for index types.Alex Zinenko2019-03-292-5/+13
| | | | | | | | | | | | | | | | | | | | | | | 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
* Materialize IndexType in the API.Alex Zinenko2019-03-294-1/+19
| | | | | | | | | | | | | | | Previously, index (aka affint) type was hidden under OtherType in the type API. We will need to identify and operate on values of index types in the upcoming MLFunc->CFGFunc(->LLVM) lowering passes. Materialize index type into a separate class and make it visible to LLVM RTTI hierarchy directly. Practically, index is an integer type of unknown bit width and is accetable in most places where regular integer types are. This is purely an API change that does not affect the IR. After IndexType is separated out from OtherType, the remaining "other types" are, in fact, TF-specific types only. Further renaming may be of interest. PiperOrigin-RevId: 220614026
OpenPOWER on IntegriCloud