summaryrefslogtreecommitdiffstats
path: root/mlir/lib/IR/MLIRContext.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix the alignment issue in the DenseElementsAttr buffer allocationFeng Liu2019-04-031-1/+6
| | | | | | | | | | | | Currently, we only make the initial address aligned with 64-bit address but allocate the buffer with the real size. This can cause issue when we extract the value by the `readBits` method, which needs to read the memory in the granularity of APINT_WORD_SIZE. In this CL, we rounded the allocation size to the multiplies of APINT_WORD_SIZE to fix the issue. -- PiperOrigin-RevId: 241816656
* Rename the 'namePrefix' field in the Dialect class to 'name' and tidy ↵River Riddle2019-03-301-4/+4
| | | | | | | | some comments to make it clear that 'name' refers to the dialect namespace. -- PiperOrigin-RevId: 241103116
* Implement basic IR support for a builtin complex<> type. As with tuples, weChris Lattner2019-03-301-1/+1
| | | | | | | | | 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
* Assert that registered dialects have unique names. This creates a ↵River Riddle2019-03-291-1/+6
| | | | | | | | guarantee that the namespace of a dialect can be used a unique key. -- PiperOrigin-RevId: 241049578
* Replace usages of Instruction with Operation in the /IR directory.River Riddle2019-03-291-1/+1
| | | | | | This is step 2/N to renaming Instruction to Operation. PiperOrigin-RevId: 240459216
* Deconst-ify MLIRContext, and detemplatize some stuff now that const is gone.Chris Lattner2019-03-291-8/+7
| | | | PiperOrigin-RevId: 239976764
* Clarify the comment on valid data during DenseElementsAttr construction.River Riddle2019-03-291-1/+1
| | | | PiperOrigin-RevId: 239958211
* Cleanup the construction of attributes and fix a opt-mode bug in ↵River Riddle2019-03-291-58/+26
| | | | | | DenseElementsAttr when allocating an empty array buffer. PiperOrigin-RevId: 239926824
* Continue pushing const out of the core IR types - in this case, remove constChris Lattner2019-03-291-2/+2
| | | | | | from Function. PiperOrigin-RevId: 239638635
* Add support for a standard TupleType. Though this is a standard type, it ↵River Riddle2019-03-291-1/+2
| | | | | | | | | | | | | | | | | | | | 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
* Rename allocator to identifierAllocator and add an identifierMutex to make ↵River Riddle2019-03-291-13/+64
| | | | | | identifier uniquing thread safe. This also adds a general purpose 'contextMutex' to protect access to the rest of the miscellaneous parts of the MLIRContext, e.g. diagnostics, dialect registration, etc. This is step 5/5 of making the MLIRContext thread-safe. PiperOrigin-RevId: 238516697
* Give the Location classes their own SmartRWMutex and make sure that they are ↵River Riddle2019-03-291-59/+44
| | | | | | using the locationAllocator. This is step 4/N to making MLIRContext thread-safe. PiperOrigin-RevId: 238516646
* Give the affine structures, AffineMap/AffineExpr/IntegerSet/etc, their own ↵River Riddle2019-03-291-67/+96
| | | | | | BumpPtrAllocator and SmartMutex to make them thread-safe. This is step 3/N to making MLIRContext thread-safe. PiperOrigin-RevId: 238516596
* Give Attributes their own BumpPtrAllocator and SmartRWMutex to make them ↵River Riddle2019-03-291-234/+280
| | | | | | thread-safe. This is step 2/N to making the MLIRContext thread-safe. PiperOrigin-RevId: 238516542
* Give the TypeUniquer its own BumpPtrAllocator and a SmartRWMutex to make it ↵River Riddle2019-03-291-7/+137
| | | | | | thread-safe. This is step 1/N to making the MLIRContext thread-safe. PiperOrigin-RevId: 238037814
* Introduce a TypeID class to provide unique identifiers for derived type ↵River Riddle2019-03-291-7/+7
| | | | | | classes. This removes the need for derived types to define a static typeID field. PiperOrigin-RevId: 237482890
* NFC. Move all of the remaining operations left in BuiltinOps to StandardOps. ↵River Riddle2019-03-291-1/+10
| | | | | | 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 a new class NamedAttributeList to deduplicate named attribute handling ↵River Riddle2019-03-291-1/+0
| | | | | | between Function and Instruction. PiperOrigin-RevId: 235830304
* Add support for constructing DenseIntElementsAttr with an array of APInt andRiver Riddle2019-03-291-6/+5
| | | | | | DenseFPElementsAttr with an array of APFloat. PiperOrigin-RevId: 235581794
* Add dialect-specific decoding for opaque constants.Tatiana Shpeisman2019-03-291-7/+15
| | | | | | | | 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 remaining references to OperationInst in all directories except for ↵River Riddle2019-03-291-1/+1
| | | | | | lib/Transforms. PiperOrigin-RevId: 232322771
* Define NumericAttr as the base class for BoolAttr, IntegerAttr, FloatAttr, ↵Lei Zhang2019-03-291-2/+6
| | | | | | | | | | | | | | and ElementsAttr These attribute kinds are different from the rest in the sense that their types are defined in MLIR's type hierarchy and we can build constant op out of them. By defining this middle-level base class, we have a unified way to test and query the type of these attributes, which will be useful when constructing constant ops of various dialects. This CL also added asserts to reject non-NumericAttr in constant op's build() method. PiperOrigin-RevId: 232188178
* Drop AffineMap::Null and IntegerSet::NullNicolas Vasilache2019-03-291-1/+1
| | | | | | | | | | | | | | | | | | | | 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
* Add a method to construct a CallSiteLoc which represents a stack of locations.Feng Liu2019-03-291-0/+11
| | | | PiperOrigin-RevId: 230592860
* Add assertions to SplatElementsAttr and ConstantOp builders and fix failuresLei Zhang2019-03-291-2/+17
| | | | | | | | | | | | | | | | | | | | | | 1) Fix FloatAttr type inconsistency in conversion from tf.FusedBatchNorm to TFLite ops We used to compose the splat tensor out of the scalar epsilon attribute by using the type of the variance operand. However, the epsilon attribute may have a different bitwidth than the one in the variance operand. So it ends up we were creating inconsistent types within the FloatAttr itself. 2) Fix SplatElementsAttr type inconsistency in AnnotateInputArrays We need to create the zero-valued attribute according to the type provided as the command-line arguments. 3) Concretize the result type of tf.Shape constant folding test case Currently the resultant constant is created by the constant folding harness, using the result type of the original op as the constant's result type. That can be a different type than the constant's internal DenseElementsAttr. PiperOrigin-RevId: 230244665
* Add a constant folding hook to ExtractElementOp to fold extracting the ↵River Riddle2019-03-291-2/+5
| | | | | | 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
* Restructure FloatAttr::get(Type, double) to allow for loss of precision when ↵River Riddle2019-03-291-23/+16
| | | | | | converting the double value to the target type semantics. A comment is added to discourage the use of this method for non simple constants. The new handling also removes the direct use of the float constructor for APFloat to avoid runtime float cast asan errors. PiperOrigin-RevId: 230014696
* Fix raw buffer size when creating a DenseElementsAttr from an array of ↵River Riddle2019-03-291-1/+3
| | | | | | attributes. PiperOrigin-RevId: 229973134
* [MLIR] Add functionality for constructing a DenseElementAttr from an array ↵River Riddle2019-03-291-25/+56
| | | | | | 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
* Move the storage of uniqued TypeStorage objects into TypeUniquer and give ↵River Riddle2019-03-291-73/+8
| | | | | | each context a unique TypeUniquer instance. PiperOrigin-RevId: 229460053
* Change derived type storage objects to define an 'operator==(const KeyTy &)' ↵River Riddle2019-03-291-6/+5
| | | | | | instead of converting to the KeyTy. This allows for handling cases where the KeyTy does not provide an equality operator on itself. PiperOrigin-RevId: 229423249
* Add a FloatAttr::getChecked, and invoke it during Attribute parsing.River Riddle2019-03-291-7/+17
| | | | PiperOrigin-RevId: 229167099
* Convert expr - c * (expr floordiv c) to expr mod c in AffineExprUday Bondhugula2019-03-291-0/+23
| | | | | | | | | | | | | | | | | | | - Detect 'mod' to replace the combination of floordiv, mul, and subtract when possible at construction time; when 'c' is a power of two, this reduces the number of operations; also more compact and readable. Update simplifyAdd for this. On a side note: - with the affine expr flattening we have, a mod expression like d0 mod c would be flattened into d0 - c * q, c * q <= d0 <= c*q + c - 1, with 'q' being added as the local variable (q = d0 floordiv c); as a result, a mod was turned into a floordiv whenever the expression was reconstructed back, i.e., as d0 - c * (d0 floordiv c); as a result of this change, we recover the mod back. - rename SimplifyAffineExpr -> SimplifyAffineStructures (pass had been renamed but the file hadn't been). PiperOrigin-RevId: 228258120
* Rename getAffineBinaryExpr -> getAffineBinaryOpExpr, getBinaryAffineOpExpr ->Uday Bondhugula2019-03-291-2/+2
| | | | | | | | getAffineBinaryOpExpr for consistency (NFC) - this is consistent with the name of the class and getAffineDimExpr/ConstantExpr, etc. PiperOrigin-RevId: 228164959
* Introduce CRTP TypeBase class to simplify type construction and validation.River Riddle2019-03-291-227/+0
| | | | | | | | | | | | | This impl class currently provides the following: * auto definition of the 'ImplType = StorageClass' * get/getChecked wrappers around TypeUniquer * 'verifyConstructionInvariants' hook - This hook verifies that the arguments passed into get/getChecked are valid to construct a type instance with. With this, all non-generic type uniquing has been moved out of MLIRContext.cpp PiperOrigin-RevId: 227871108
* Introduce a simple canonicalization of affine_apply that drops unused dims andChris Lattner2019-03-291-9/+5
| | | | | | | | | | | | | | | | | | | symbols. Included with this is some other infra: - Testcases for other canonicalizations that I will implement next. - Some helpers in AffineMap/Expr for doing simple walks without defining whole visitor classes. - A 'replaceDimsAndSymbols' facility that I'll be using to simplify maps and exprs, e.g. to fold one constant into a mapping and to drop/renumber unused dims. - Allow index (and everything else) to work in memref's, as we previously discussed, to make the testcase easier to write. - A "getAffineBinaryExpr" helper to produce a binop when you know the kind as an enum. This line of work will eventually subsume the ComposeAffineApply pass, but it is no where close to that yet :-) PiperOrigin-RevId: 227852951
* Split the standard types from builtin types and move them into separate ↵River Riddle2019-03-291-14/+16
| | | | | | source files(StandardTypes.cpp/h). After this cl only FunctionType and IndexType are builtin types, but IndexType will likely become a standard type when the ml/cfgfunc merger is done. Mechanical NFC. PiperOrigin-RevId: 227750918
* Implement initial support for dialect specific types.River Riddle2019-03-291-6/+22
| | | | | | | | | | | | | | | | | | | | | | | | | Dialect specific types are registered similarly to operations, i.e. registerType<...> within the dialect. Unlike operations, there is no notion of a "verbose" type, that is *all* types must be registered to a dialect. Casting support(isa/dyn_cast/etc.) is implemented by reserving a range of type kinds in the top level Type class as opposed to string comparison like operations. To support derived types a few hooks need to be implemented: In the concrete type class: - static char typeID; * A unique identifier for the type used during registration. In the Dialect: - typeParseHook and typePrintHook must be implemented to provide parser support. The syntax for dialect extended types is as follows: dialect-type: '!' dialect-namespace '<' '"' type-specific-data '"' '>' The 'type-specific-data' is information used to identify different types within the dialect, e.g: - !tf<"variant"> // Tensor Flow Variant Type - !tf<"string"> // Tensor Flow String Type TensorFlow/TensorFlowControl types are now implemented as dialect specific types as a proof of concept. PiperOrigin-RevId: 227580052
* Rename OperationPrefix to Namespace in Dialect. This is important as ↵River Riddle2019-03-291-13/+9
| | | | | | | | | | dialects will soon be able to define more than just operations. Moving forward dialect namespaces cannot contain '.' characters. This cl also standardizes that operation names must begin with the dialect namespace followed by a '.'. PiperOrigin-RevId: 227532193
* Merge Operation into OperationInst and standardize nomenclature aroundChris Lattner2019-03-291-1/+1
| | | | | | | | OperationInst. This is a big mechanical patch. This is step 16/n towards merging instructions and statements, NFC. PiperOrigin-RevId: 227093712
* Support NameLoc and CallSiteLoc for mlir::LocationFeng Liu2019-03-291-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The NameLoc can be used to represent a variable, node or method. The CallSiteLoc has two fields, one represents the concrete location and another one represents the caller's location. Multiple CallSiteLocs can be chained as a call stack. For example, the following call stack ``` AAA at file1:1 at file2:135 at file3:34 ``` can be formed by call0: ``` auto name = NameLoc::get("AAA"); auto file1 = FileLineColLoc::get("file1", 1); auto file2 = FileLineColLoc::get("file2", 135); auto file3 = FileLineColLoc::get("file3", 34); auto call2 = CallSiteLoc::get(file2, file3); auto call1 = CallSiteLoc::get(file1, call2); auto call0 = CallSiteLoc::get(name, call1); ``` PiperOrigin-RevId: 226941797
* Unify type uniquing and construction.River Riddle2019-03-291-294/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-291-27/+10
| | | | | | | | | | | | | | | | | | 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-291-4/+11
| | | | | | | | | | | | | | | | | | | | | | | 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-291-1/+48
| | | | | | | | | | | | 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-291-1/+2
| | | | | | | | | | | | | 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
* 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
OpenPOWER on IntegriCloud