summaryrefslogtreecommitdiffstats
path: root/mlir/lib/IR
Commit message (Collapse)AuthorAgeFilesLines
...
* Add iterator support to ElementsAttr and SparseElementsAttr.River Riddle2019-08-221-28/+71
| | | | | | This will allow iterating the values of a non-opaque ElementsAttr, with all of the types currently supported by DenseElementsAttr. This should help reduce the amount of specialization on DenseElementsAttr. PiperOrigin-RevId: 264968151
* Add a hook to the OpAsmDialectInterface to allow providing a special name ↵River Riddle2019-08-211-23/+15
| | | | | | | | for the operation result. This generalizes the current special handling for constant operations(they get named 'cst'/'true'/'false'/etc.) PiperOrigin-RevId: 264723379
* Automated rollback of commit b9dc2e481818315f2f0d87455349f497f6118a4cRiver Riddle2019-08-211-71/+28
| | | | PiperOrigin-RevId: 264672975
* NFC: Make the ModuleState field in the ModulePrinter optional.River Riddle2019-08-211-43/+35
| | | | | | The ModuleState is only used for printing aliases, which is only done when printing the top-level module. PiperOrigin-RevId: 264664138
* Add iterator support to ElementsAttr and SparseElementsAttr.River Riddle2019-08-211-28/+71
| | | | | | This will allow iterating the values of a non-opaque ElementsAttr, with all of the types currently supported by DenseElementsAttr. This should help reduce the amount of specialization on DenseElementsAttr. PiperOrigin-RevId: 264637293
* Move the parser extensions for aliases currently on Dialect to a new ↵River Riddle2019-08-212-12/+16
| | | | | | | | OpAsmDialectInterface. This will allow for adding more hooks for controlling parser behavior without bloating Dialect in the common case. This cl also adds iteration support to the DialectInterfaceCollection. PiperOrigin-RevId: 264627846
* NFC: Keep the dialect list in the context sorted by namespace.River Riddle2019-08-201-6/+14
| | | | | | Most dialects are initialized statically, which does not have a guaranteed initialization order. By keeping the dialect list sorted, we can guarantee a deterministic iteration order of dialects. PiperOrigin-RevId: 264522875
* NFC: Use a DenseSet instead of a DenseMap for DialectInterfaceCollection.River Riddle2019-08-201-2/+2
| | | | | | The interfaces are looked up by dialect, which can always be retrieved from an interface instance. PiperOrigin-RevId: 264516023
* Fix build of affine load/store with empty mapDiego Caballero2019-08-205-6/+9
| | | | | | | | | | | | | | | tensorflow/mlir#58 fixed and exercised verification of load/store ops using empty affine maps. Unfortunately, it didn't exercise the creation of them. This PR addresses that aspect. It removes the assumption of AffineMap having at least one result and stores a pointer to MLIRContext as member of AffineMap. * Add empty map support to affine.store + test * Move MLIRContext to AffineMapStorage Closes tensorflow/mlir#74 PiperOrigin-RevId: 264416260
* Add support for LLVM lowering of binary ops on n-D vector typesNicolas Vasilache2019-08-201-0/+9
| | | | | | This CL allows binary operations on n-D vector types to be lowered to LLVMIR by performing an (n-1)-D extractvalue, 1-D vector operation and an (n-1)-D insertvalue. PiperOrigin-RevId: 264339118
* Fix AffineExpr::simplifyAdd bugUday Bondhugula2019-08-201-1/+1
| | | | | | | | | | | | - fix missing check while simplifying an expression with floordiv to a mod - fixes issue tensorflow/mlir#82 Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#84 PiperOrigin-RevId: 264338353
* Change from llvm::make_unique to std::make_uniqueJacques Pienaar2019-08-171-1/+1
| | | | | | | | Switch to C++14 standard method as llvm::make_unique has been removed ( https://reviews.llvm.org/D66259). Also mark some targets as c++14 to ease next integrates. PiperOrigin-RevId: 263953918
* NFC: Add header blocks to improve readability.River Riddle2019-08-171-2/+10
| | | | PiperOrigin-RevId: 263951251
* NFC: Move the Type::is* predicates to StandardTypes.cppRiver Riddle2019-08-161-0/+26
| | | | | | These methods are currently defined 'inline' in StandardTypes.h, but this may create linker errors if StandardTypes.h isn't included at the use site. PiperOrigin-RevId: 263850328
* Add support for Dialect interfaces.River Riddle2019-08-141-1/+42
| | | | | | | | | | Dialect interfaces are virtual apis registered to a specific dialect instance. Dialect interfaces are generally useful for transformation passes, or analyses, that want to opaquely operate on operations within a given dialect. These interfaces generally involve wide coverage over the entire dialect. A dialect interface can be defined by inheriting from the CRTP base class DialectInterfaceBase::Base. This class provides the necessary utilities for registering an interface with the dialect so that it can be looked up later. Dialects overriding an interface may register an instance via 'Dialect::addInterfaces'. This API works very similarly to the respective addOperations/addTypes/etc. This will allow for a transformation/utility to later query the interface from an opaque dialect instance via 'getInterface<T>'. A utility class 'DialectInterfaceCollection' is also provided that will collect all of the dialects that implement a specific interface within a given module. This allows for simplifying the API of interface lookups. PiperOrigin-RevId: 263489015
* Refactor ElementsAttr::getValue and DenseElementsAttr::getSplatValue.River Riddle2019-08-141-57/+63
| | | | | | All 'getValue' variants now require that the index is valid, queryable via 'isValidIndex'. 'getSplatValue' now requires that the attribute is a proper splat. This allows for querying these methods on DenseElementAttr with all possible value types; e.g. float, int, APInt, etc. This also allows for removing unnecessary conversions to Attribute that really want the underlying value. PiperOrigin-RevId: 263437337
* Avoid passing in line/col for files not registered with SourceMgr.Jacques Pienaar2019-08-121-6/+4
| | | | | | | | | This can result in index expression overflow in "Loc.getPointer() - ColumnNo" in SourgeMgr. loc could also be prefixed to the message additionally in this case. PiperOrigin-RevId: 262935408
* NFC: Update pattern rewrite API to pass OwningRewritePatternList by const ↵River Riddle2019-08-111-1/+1
| | | | | | | | reference. The pattern list is not modified by any of these APIs and should thus be passed with const. PiperOrigin-RevId: 262844002
* Refactor DenseElementAttr::getValues methods to return full ranges for splats.River Riddle2019-08-112-19/+31
| | | | | | The current implementation only returns one element for the splat case, which often comes as a surprise; leading to subtle/confusing bugs. The new behavior will include an iterate over the full range of elements, as defined by the shaped type, by providing the splat value for each iterator index. PiperOrigin-RevId: 262756780
* NFC: Standardize the terminology used for parent ops/regions/etc.River Riddle2019-08-095-22/+22
| | | | | | There are currently several different terms used to refer to a parent IR unit in 'get' methods: getParent/getEnclosing/getContaining. This cl standardizes all of these methods to use 'getParent*'. PiperOrigin-RevId: 262680287
* FunctionSupport: wrap around bool to have a more semantic callback typeAlex Zinenko2019-08-082-3/+4
| | | | | | | | | | | | This changes the type of the function type-building callback from (ArrayRef<Type>, ArrayRef<Type>, bool, string &) to (ArrayRef<Type>, ArrayRef<Type>, VariadicFlag, String &) to make the intended use clear from the callback signature alone. Also rearrange type definitions in Parser.cpp to make them more sorted alphabetically. PiperOrigin-RevId: 262405851
* Introduce support for variadic function signatures for the LLVM dialectAlex Zinenko2019-08-082-15/+44
| | | | | | | | | | | | | LLVM function type has first-class support for variadic functions. In the current lowering pipeline, it is emulated using an attribute on functions of standard function type. In LLVMFuncOp that has LLVM function type, this can be modeled directly. Introduce parsing support for variadic arguments to the function and use it to support variadic function declarations in LLVMFuncOp. Function definitions are currently not supported as that would require modeling va_start/va_end LLVM intrinsics in the dialect and we don't yet have a consistent story for LLVM intrinsics. PiperOrigin-RevId: 262372651
* NFC: Update FuncOp::addEntryBlock to return the newly inserted block.River Riddle2019-08-071-1/+2
| | | | | | The entry block is often used recently after insertion. This removes the need to perform an additional lookup in such cases. PiperOrigin-RevId: 262265671
* Add utility 'replaceAllUsesWith' methods to Operation.River Riddle2019-08-071-2/+1
| | | | | | These methods will allow replacing the uses of results with an existing operation, with the same number of results, or a range of values. This removes a number of hand-rolled result replacement loops and simplifies replacement for operations with multiple results. PiperOrigin-RevId: 262206600
* Improve support for opaque types in MLIR, allowing dialects to opt intoChris Lattner2019-08-072-1/+17
| | | | | | supporting opaque types, and providing ODS support for matching them. PiperOrigin-RevId: 262183028
* Fix verification of zero-dim memref in ↵Diego Caballero2019-08-072-6/+17
| | | | | | | | | | | | | affine.load/affine.store/std.load/std.store Verification complained when using zero-dimensional memrefs in affine.load, affine.store, std.load and std.store. This PR extends verification so that those memrefs can be used. Closes tensorflow/mlir#58 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/58 from dcaballe:dcaballe/zero-dim 49bcdcd45c52c48beca776431328e5ce551dfa9e PiperOrigin-RevId: 262164916
* NFC: Simplify ModuleTerminatorOp by using the HasParent trait.River Riddle2019-08-061-11/+0
| | | | PiperOrigin-RevId: 261962104
* NFC: Simplify ModuleOp by using the SingleBlockImplicitTerminator trait.River Riddle2019-08-061-18/+2
| | | | PiperOrigin-RevId: 261944712
* NFC: Implement OwningRewritePatternList as a class instead of a using directive.River Riddle2019-08-051-5/+6
| | | | | | This allows for proper forward declaration, as opposed to leaking the internal implementation via a using directive. This also allows for all pattern building to go through 'insert' methods on the OwningRewritePatternList, replacing uses of 'push_back' and 'RewriteListBuilder'. PiperOrigin-RevId: 261816316
* Introduce custom syntax for llvm.funcAlex Zinenko2019-08-052-4/+9
| | | | | | | Similar to all LLVM dialect operations, llvm.func needs to have the custom syntax. Use the generic FunctionLike printer and parser to implement it. PiperOrigin-RevId: 261641755
* Add a generic Linalg opNicolas Vasilache2019-08-022-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL introduces a linalg.generic op to represent generic tensor contraction operations on views. A linalg.generic operation requires a numbers of attributes that are sufficient to emit the computation in scalar form as well as compute the appropriate subviews to enable tiling and fusion. These attributes are very similar to the attributes for existing operations such as linalg.matmul etc and existing operations can be implemented with the generic form. In the future, most existing operations can be implemented using the generic form. This CL starts by splitting out most of the functionality of the linalg::NInputsAndOutputs trait into a ViewTrait that queries the per-instance properties of the op. This allows using the attribute informations. This exposes an ordering of verifiers issue where ViewTrait::verify uses attributes but the verifiers for those attributes have not been run. The desired behavior would be for the verifiers of the attributes specified in the builder to execute first but it is not the case atm. As a consequence, to emit proper error messages and avoid crashing, some of the linalg.generic methods are defensive as such: ``` unsigned getNumInputs() { // This is redundant with the `n_views` attribute verifier but ordering of verifiers // may exhibit cases where we crash instead of emitting an error message. if (!getAttr("n_views") || n_views().getValue().size() != 2) return 0; ``` In pretty-printed form, the specific attributes required for linalg.generic are factored out in an independent dictionary named "_". When parsing its content is flattened and the "_name" is dropped. This allows using aliasing for reducing boilerplate at each linalg.generic invocation while benefiting from the Tablegen'd verifier form for each named attribute in the dictionary. For instance, implementing linalg.matmul in terms of linalg.generic resembles: ``` func @mac(%a: f32, %b: f32, %c: f32) -> f32 { %d = mulf %a, %b: f32 %e = addf %c, %d: f32 return %e: f32 } #matmul_accesses = [ (m, n, k) -> (m, k), (m, n, k) -> (k, n), (m, n, k) -> (m, n) ] #matmul_trait = { doc = "C(m, n) += A(m, k) * B(k, n)", fun = @mac, indexing_maps = #matmul_accesses, library_call = "linalg_matmul", n_views = [2, 1], n_loop_types = [2, 1, 0] } ``` And can be used in multiple places as: ``` linalg.generic #matmul_trait %A, %B, %C [other-attributes] : !linalg.view<?x?xf32>, !linalg.view<?x?xf32>, !linalg.view<?x?xf32> ``` In the future it would be great to have a mechanism to alias / register a new linalg.op as a pair of linalg.generic, #trait. Also, note that with one could theoretically only specify the `doc` string and parse all the attributes from it. PiperOrigin-RevId: 261338740
* Add missing include to DenseMap in MLIRContext.cppMehdi Amini2019-08-011-0/+1
| | | | | | This is fixing the build of MLIR on MacOS when built within TensorFlow PiperOrigin-RevId: 261223250
* Add support for hexadecimal float literalsAlex Zinenko2019-07-301-5/+14
| | | | | | | | | | | | | | | | | | | | 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
* Automated rollback of commit fc194a4f22fe53f46729821d9c4a993fe200facfMehdi Amini2019-07-251-5/+1
| | | | PiperOrigin-RevId: 260037115
* Genericize function-like printer and parser. NFCAlex Zinenko2019-07-252-160/+210
| | | | | | | | | | | | | Function-like operations are likely to have similar custom syntax, in particular they all need to print function signature with argument attributes. Transform function printer and parser so that they can be applied to any operation with the FunctionLike trait. Move them to the trait itself. To avoid large member functions in the class template, define a concrete base class for the trait and implement common functionality in it. This allows printer and parser to be implemented in a source file without templating. PiperOrigin-RevId: 260020893
* Add support for hexadecimal float literalsAlex Zinenko2019-07-251-1/+5
| | | | | | | | | | | | | 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. PiperOrigin-RevId: 260018802
* Introduce LLVMFuncOpAlex Zinenko2019-07-231-99/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally, MLIR only supported functions of the built-in FunctionType. On the conversion path to LLVM IR, we were creating MLIR functions that contained LLVM dialect operations and used LLVM IR types for everything expect top-level functions (e.g., a second-order function would have a FunctionType that consume or produces a wrapped LLVM function pointer type). With MLIR functions becoming operations, it is now possible to introduce non-built-in function operations. This will let us use conversion patterns for function conversion, simplify the MLIR-to-LLVM translation by removing the knowledge of the MLIR built-in function types, and provide stronger correctness verifications (e.g. LLVM functions only accept LLVM types). Furthermore, we can currently construct a situation where the same function is used with two different types: () -> () when its specified and called directly, and !llvm<"void ()"> when it's passed somewhere on called indirectly. Having a special function-op that is always of !llvm<"void ()"> type makes the function model and the llvm dialect type system more consistent. Introduce LLVMFuncOp to represent a function in the LLVM dialect. Unlike standard FuncOp, this function has an LLVMType wrapping an LLVM IR function type. Generalize the common behavior of function-defining operations (functions live in a symbol table of a module, contain a single region, are iterable as a list of blocks, and support argument attributes). This only defines the operation. Custom syntax, conversion and translation rules will be added in follow-ups. The operation name mentions LLVM explicitly to avoid confusion with standard FuncOp, especially in multiple files that use both `mlir` and `mlir::LLVM` namespaces. PiperOrigin-RevId: 259550940
* Update style/clang-format (NFC).Jacques Pienaar2019-07-221-19/+19
| | | | | | Update to be consistent & so that future save + clang-format workflows don't introduce extra changes. PiperOrigin-RevId: 259361174
* (De)serialize bool and integer scalar spv.constantLei Zhang2019-07-221-1/+5
| | | | | | | | | | | | | | | | | | | | | SPIR-V has multiple constant instructions covering different constant types: * `OpConstantTrue` and `OpConstantFalse` for boolean constants * `OpConstant` for scalar constants * `OpConstantComposite` for composite constants * `OpConstantNull` for null constants * ... We model them all with a single spv.constant op for uniformity and friendliness to transformations. This does mean that when doing (de)serialization, we need to poke spv.constant's type to determine which SPIR-V binary instruction to use. This CL only covers the case of bool and integer spv.constant. The rest will follow. PiperOrigin-RevId: 259311698
* Ensure that DenseElementAttr data is 64-bit aligned.River Riddle2019-07-201-7/+14
| | | | | | This allows for the raw data to be reinterpreted as the derived c++ type, e.g. ArrayRef<uint64_t>. This fixes a ubsan error for misaligned-pointer-use. PiperOrigin-RevId: 259128031
* Merge TypeUtilities library into the IR libraryAlex Zinenko2019-07-201-0/+66
| | | | | | | | | | The TypeUtilities.{cpp,h}, currently living in {lib,include/mlir}/Support, do not belong to the Support library. Instead, they form a separate utility library that depends on the IR library. The operations it provides relate to standard types (tensors, memrefs) as well as to operation manipulation, making them a better fit for the main IR library. PiperOrigin-RevId: 259108314
* Print boolean values in ElementsAttr as "true"/"false"Lei Zhang2019-07-191-1/+4
| | | | | | | 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
* Add support for parsing/printing the trailing type of a dialect attribute.River Riddle2019-07-193-12/+18
| | | | | | | | | | 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
* Refactor the conversion of block argument types in DialectConversion.River Riddle2019-07-192-0/+14
| | | | | | | | This cl begins a large refactoring over how signature types are converted in the DialectConversion infrastructure. The signatures of blocks are now converted on-demand when an operation held by that block is being converted. This allows for handling the case where a region is created as part of a pattern, something that wasn't possible previously. This cl also generalizes the region signature conversion used by FuncOp to work on any region of any operation. This generalization allows for removing the 'apply*Conversion' functions that were specific to FuncOp/ModuleOp. The implementation currently uses a new hook on TypeConverter, 'convertRegionSignature', but this should ideally be removed in favor of using Patterns. That depends on adding support to the PatternRewriter used by ConversionPattern to allow applying signature conversions to regions, which should be coming in a followup. PiperOrigin-RevId: 258645733
* NFC: Don't print the location of a diagnostic if it is unknown.River Riddle2019-07-121-2/+4
| | | | | | Printing 'loc(unknown)' just clutters the output with unhelpful information. PiperOrigin-RevId: 257883717
* Remove the 'region' field from OpBuilder.River Riddle2019-07-121-14/+22
| | | | | | This field wasn't updated as the insertion point changed, making it potentially dangerous given the multi-level of MLIR(e.g. 'createBlock' would always insert the new block in 'region'). This also allows for building an OpBuilder with just a context. PiperOrigin-RevId: 257829135
* Update the dialect attribute verifiers related to functions.River Riddle2019-07-122-13/+9
| | | | | | Remove the Function specific attribute verifier in favor of the general operation verifier. This also generalizes the function argument verifier to allow use for an argument attached to any region of any operation. PiperOrigin-RevId: 257689962
* Rename FunctionAttr to SymbolRefAttr.River Riddle2019-07-125-15/+17
| | | | | | This allows for the attribute to hold symbolic references to other operations than FuncOp. This also allows for removing the dependence on FuncOp from the base Builder. PiperOrigin-RevId: 257650017
* FuncOp::eraseBody: drop all references before erasing blocksAlex Zinenko2019-07-123-4/+15
| | | | | | | | | | Operations in a block can use a value defined in a dominating block. When a block, and therefore all its operations, is deleted, the operations are not allowed to have any remaining uses. Drop all uses of values in all blocks before deleting them in FuncOp::eraseBody to avoid deleting an operation before deleting the users of its results. PiperOrigin-RevId: 257628002
* NFC: Replace Module::getNamedFunction with lookupSymbol<FuncOp>.River Riddle2019-07-121-0/+1
| | | | | | This allows for removing the last direct reference to FuncOp from ModuleOp. PiperOrigin-RevId: 257498296
OpenPOWER on IntegriCloud