summaryrefslogtreecommitdiffstats
path: root/mlir/examples/toy
Commit message (Collapse)AuthorAgeFilesLines
...
* NFC: Update Ch.1 of the Toy tutorial.River Riddle2019-08-232-7/+5
| | | | | | Change the use of 'array' to 'tensor' to reflect the new flow that the tutorial will follow. Also tidy up some of the documentation, code comments, and fix a few out-dated links. PiperOrigin-RevId: 265174676
* NFC: Move LLVMIR, SDBM, and StandardOps to the Dialect/ directory.River Riddle2019-08-198-8/+8
| | | | PiperOrigin-RevId: 264193915
* Change from llvm::make_unique to std::make_uniqueJacques Pienaar2019-08-1713-117/+107
| | | | | | | | 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
* Refactor ElementsAttr::getValue and DenseElementsAttr::getSplatValue.River Riddle2019-08-141-6/+2
| | | | | | 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
* Express ownership transfer in PassManager API through std::unique_ptr (NFC)Mehdi Amini2019-08-129-8/+22
| | | | | | | | | | | | | | Since raw pointers are always passed around for IR construct without implying any ownership transfer, it can be error prone to have implicit ownership transferred the same way. For example this code can seem harmless: Pass *pass = .... pm.addPass(pass); pm.addPass(pass); pm.run(module); PiperOrigin-RevId: 263053082
* NFC: Standardize the terminology used for parent ops/regions/etc.River Riddle2019-08-091-1/+1
| | | | | | 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
* NFC: Update usages of OwningRewritePatternList to pass by & instead of &&.River Riddle2019-08-092-4/+3
| | | | | | This will allow for reusing the same pattern list, which may be costly to continually reconstruct, on multiple invocations. PiperOrigin-RevId: 262664599
* NFC: Update FuncOp::addEntryBlock to return the newly inserted block.River Riddle2019-08-074-12/+4
| | | | | | 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 TTI pass initialization to pass managers.Diego Caballero2019-08-051-2/+4
| | | | | | | | | Many LLVM transformations benefits from knowing the targets. This enables optimizations, especially in a JIT context when the target is (generally) well-known. Closes tensorflow/mlir#49 PiperOrigin-RevId: 261840617
* NFC: Implement OwningRewritePatternList as a class instead of a using directive.River Riddle2019-08-054-11/+11
| | | | | | 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
* Refactor region type signature conversion to be explicit via patterns.River Riddle2019-07-201-0/+5
| | | | | | This cl enforces that the conversion of the type signatures for regions, and thus their entry blocks, is handled via ConversionPatterns. A new hook 'applySignatureConversion' is added to the ConversionPatternRewriter to perform the desired conversion on a region. This also means that the handling of rewriting the signature of a FuncOp is moved to a pattern. A default implementation is provided via 'mlir::populateFuncOpTypeConversionPattern'. This removes the hacky implicit 'dynamically legal' status of FuncOp that was present previously, and leaves it up to the user to decide when/how to convert the signature of a function. PiperOrigin-RevId: 259161999
* NFC: Expose a ConversionPatternRewriter for use with ConversionPatterns.River Riddle2019-07-192-14/+20
| | | | | | This specific PatternRewriter will allow for exposing hooks in the future that are only useful for the conversion framework, e.g. type conversions. PiperOrigin-RevId: 258818122
* Refactor the conversion of block argument types in DialectConversion.River Riddle2019-07-191-2/+2
| | | | | | | | 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
* Refactor DialectConversion to support different conversion modes.River Riddle2019-07-162-4/+4
| | | | | | | | | | | Users generally want several different modes of conversion. This cl refactors DialectConversion to provide two: * Partial (applyPartialConversion) - This mode allows for illegal operations to exist in the IR, and does not fail if an operation fails to be legalized. * Full (applyFullConversion) - This mode fails if any operation is not properly legalized to the conversion target. This allows for ensuring that the IR after a conversion only contains operations legal for the target. PiperOrigin-RevId: 258412243
* Remove the 'region' field from OpBuilder.River Riddle2019-07-121-1/+1
| | | | | | 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
* NFC: Remove redundant call to registerPassManagerCLOptions from MLIR tutorialSmit Hinsu2019-07-121-3/+0
| | | | | | | main already calls registerPassManagerCLOptions. TESTED = not (NFC) PiperOrigin-RevId: 257722013
* Rename FunctionAttr to SymbolRefAttr.River Riddle2019-07-125-4/+8
| | | | | | 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
* NFC: Replace Module::getNamedFunction with lookupSymbol<FuncOp>.River Riddle2019-07-123-9/+13
| | | | | | This allows for removing the last direct reference to FuncOp from ModuleOp. PiperOrigin-RevId: 257498296
* NFC: Rename Module to ModuleOp.River Riddle2019-07-107-10/+10
| | | | | | Module is a legacy name that only exists as a typedef of ModuleOp. PiperOrigin-RevId: 257427248
* Update ModuleOp::create(...) to take a Location instead of a context.River Riddle2019-07-104-4/+4
| | | | | | This allows for giving a Module a more interesting location than 'Unknown'. PiperOrigin-RevId: 257310117
* NFC: Rename Function to FuncOp.River Riddle2019-07-107-37/+37
| | | | PiperOrigin-RevId: 257293379
* NFC: Remove `Module::getFunctions` in favor of a general `getOps<T>`.River Riddle2019-07-083-5/+7
| | | | | | Modules can now contain more than just Functions, this just updates the iteration API to reflect that. The 'begin'/'end' methods have also been updated to iterate over opaque Operations. PiperOrigin-RevId: 257099084
* NFC: Remove the various "::getFunction" methods.River Riddle2019-07-081-1/+1
| | | | | | These methods assume that a function is a valid builtin top-level operation, and removing these methods allows for decoupling FuncOp and IR/. Utility "getParentOfType" methods have been added to Operation/OpState to allow for querying the first parent operation of a given type. PiperOrigin-RevId: 257018913
* Remove std::move of trivially-copyable type.Jacques Pienaar2019-07-081-1/+1
| | | | | | | | Address ClangTidy finding: * std::move of the expression of the trivially-copyable type 'mlir::Module' (aka 'mlir::ModuleOp') has no effect; remove std::move() PiperOrigin-RevId: 256981849
* Replace the implementation of Function and Module with FuncOp and ModuleOp.River Riddle2019-07-032-4/+6
| | | | | | This is an important step in allowing for the top-level of the IR to be extensible. FuncOp and ModuleOp contain all of the necessary functionality, while using the existing operation infrastructure. As an interim step, many of the usages of Function and Module, including the name, will remain the same. In the future, many of these will be relaxed to allow for many different types of top-level operations to co-exist. PiperOrigin-RevId: 256427100
* NFC: Move the Function/Module/Operation::verify methods out-of-line.River Riddle2019-07-0210-12/+22
| | | | | | As Functions/Modules becomes operations, these methods will conflict with the 'verify' hook already on derived operation types. PiperOrigin-RevId: 256246112
* NFC: Refactor Module to be value typed.River Riddle2019-07-0215-56/+52
| | | | | | As with Functions, Module will soon become an operation, which are value-typed. This eases the transition from Module to ModuleOp. A new class, OwningModuleRef is provided to allow for owning a reference to a Module, and will auto-delete the held module on destruction. PiperOrigin-RevId: 256196193
* NFC: Refactor Function to be value typed.River Riddle2019-07-017-117/+125
| | | | | | Move the data members out of Function and into a new impl storage class 'FunctionStorage'. This allows for Function to become value typed, which will greatly simplify the transition of Function to FuncOp(given that FuncOp is also value typed). PiperOrigin-RevId: 255983022
* Extract the automatic function renaming and symbol table out of Module.River Riddle2019-07-011-7/+9
| | | | | | This functionality is now moved to a new class, ModuleManager. This class allows for inserting functions into a module, and will auto-rename them on insert to ensure a unique name. This now means that users adding new functions to a module must ensure that the function name is unique, as the Module will no longer do it automatically. This also means that Module::getNamedFunction now operates in O(N) instead of the O(c) time it did before. This simplifies the move of Modules to Operations as the ModuleOp will not be able to have this functionality. PiperOrigin-RevId: 255846088
* Refactor DialectConversion to use 'materializeConversion' when a type ↵River Riddle2019-06-281-0/+8
| | | | | | | | conversion must persist after the conversion has finished. During conversion, if a type conversion has dangling uses a type conversion must persist after conversion has finished to maintain valid IR. In these cases, we now query the TypeConverter to materialize a conversion for us. This allows for the default case of a full conversion to continue working as expected, but also handle the degenerate cases more robustly. PiperOrigin-RevId: 255637171
* Move the emitError/Warning/Remark utility methods out of MLIRContext and ↵River Riddle2019-06-2511-114/+81
| | | | | | | | into the mlir namespace. Now that Locations are attributes, they have direct access to the MLIR context. This allows for simplifying error emission by removing unnecessary context lookups. PiperOrigin-RevId: 255112791
* NFC: Uniformize the return of the LocationAttr 'get' methods to 'Location'.River Riddle2019-06-254-4/+4
| | | | PiperOrigin-RevId: 255078768
* NFC: Remove the 'context' parameter from OperationState.River Riddle2019-06-221-8/+8
| | | | | | Now that Locations are Attributes they contain a direct reference to the MLIRContext, i.e. the context can be directly accessed from the given location instead of being explicitly passed in. PiperOrigin-RevId: 254568329
* Replace usages of 'UniquedFilename' with 'Identifier' and remove it. ↵River Riddle2019-06-194-12/+8
| | | | | | Identifier already contains all of the necessary functionality/verification, so having a separate class for filenames is unnecessary. PiperOrigin-RevId: 253855505
* Remove dead code.Jing Pu2019-06-191-11/+0
| | | | PiperOrigin-RevId: 253314416
* NFC: Cleanup the naming scheme for registering legalization actions to be ↵River Riddle2019-06-112-3/+3
| | | | | | consistent, and move a file functions to the source file. PiperOrigin-RevId: 252639629
* Remove the ability to directly construct a DenseElementsAttr with a raw ↵River Riddle2019-06-092-4/+2
| | | | | | | | | character buffer. This made assumptions about how DenseElementsAttr structured its internal storage, which may change in the future. To replace the existing use cases, a few utility methods have been added: * 'get' methods that allow constructing from an ArrayRef of integer or floating point values. * A 'reshape' method to allow for changing the shape without changing the underlying data. PiperOrigin-RevId: 252067898
* Add support for matchAndRewrite to the DialectConversion patterns. This also ↵River Riddle2019-06-092-12/+18
| | | | | | drops the default "always succeed" match override to better align with RewritePattern. PiperOrigin-RevId: 251941625
* NFC: Rename FuncBuilder to OpBuilder and refactor to take a top level region ↵River Riddle2019-06-098-17/+17
| | | | | | instead of a function. PiperOrigin-RevId: 251563898
* Refactor the dialect conversion framework to support multi-level ↵River Riddle2019-06-032-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | conversions. Multi-level conversions are those that require multiple patterns to be applied before an operation is completely legalized. This essentially means that conversion patterns do not have to directly generate legal operations, and may be chained together to produce legal code. To accomplish this, moving forward users will need to provide a legalization target that defines what operations are legal for the conversion. A target can mark an operation as legal by providing a specific legalization action. The initial actions are: * Legal - This action signals that every instance of the given operation is legal, i.e. any combination of attributes, operands, types, etc. is valid. * Dynamic - This action signals that only some instances of a given operation are legal. This allows for defining fine-tune constraints, like say std.add is only legal when operating on 32-bit integers. An example target is shown below: struct MyTarget : public ConversionTarget { MyTarget(MLIRContext &ctx) : ConversionTarget(ctx) { // All operations in the LLVM dialect are legal. addLegalDialect<LLVMDialect>(); // std.constant op is always legal on this target. addLegalOp<ConstantOp>(); // std.return op has dynamic legality constraints. addDynamicallyLegalOp<ReturnOp>(); } /// Implement the custom legalization handler to handle /// std.return. bool isLegal(Operation *op) override { // Process the dynamic handling for a std.return op (and any others that were // marked "dynamic"). ... } }; PiperOrigin-RevId: 251289374
* Replace a usage of std::vector with SmallVector to allow constructing ↵River Riddle2019-06-012-10/+6
| | | | | | | | with non-constant iterators on MSVC. -- PiperOrigin-RevId: 250769027
* Add a templated wrapper around RewritePattern that allows for defining ↵River Riddle2019-06-012-94/+61
| | | | | | | | match/rewrite methods with an instance of the source op instead of a raw Operation*. -- PiperOrigin-RevId: 250003405
* Rename DialectConversion to TypeConverter and split out pattern ↵River Riddle2019-06-012-38/+17
| | | | | | | | construction. This simplifies building the conversion pattern list from multiple sources. -- PiperOrigin-RevId: 249930583
* Add operand type iterators to Operation and cleanup usages of ↵River Riddle2019-06-012-13/+9
| | | | | | | | operand->getType. This also simplifies some lingering usages of result->getType. -- PiperOrigin-RevId: 249889174
* NFC: Rename DialectConversionPattern to ConversionPattern.River Riddle2019-06-012-18/+14
| | | | | | -- PiperOrigin-RevId: 249857277
* Decouple running a conversion from the DialectConversion class. The ↵River Riddle2019-06-012-3/+5
| | | | | | | | DialectConversion class is only necessary for type signature changes(block arguments or function arguments). This isn't always desired when performing a dialect conversion. This allows for those conversions without this need to run per function instead of per module. -- PiperOrigin-RevId: 249657549
* Add thread-safe utilities to LLVMType to allow constructing llvm types ↵River Riddle2019-06-011-7/+3
| | | | | | | | in a multi-threaded environment. The LLVMContext is not thread-safe and directly constructing a raw llvm::Type can create situations where the LLVMContext is modified by multiple threads at the same time. -- PiperOrigin-RevId: 249526233
* Fix a bug in toy LateLowering where a type conversion was using 'cast' ↵River Riddle2019-06-011-1/+1
| | | | | | | | instead of 'dyn_cast'. -- PiperOrigin-RevId: 249325111
* Use lambdas for nesting edsc constructs.Nicolas Vasilache2019-05-201-11/+12
| | | | | | | | | | | Using ArrayRef introduces issues with the order of evaluation between a constructor and the arguments of the subsequent calls to the `operator()`. As a consequence the order of captures is not well-defined can go wrong with certain compilers (e.g. gcc-6.4). This CL fixes the issue by using lambdas in lieu of ArrayRef. -- PiperOrigin-RevId: 249114775
* ExecutionEngine: drop PassManager integrationAlex Zinenko2019-05-201-5/+2
| | | | | | | | | | | | | | | Originally, ExecutionEngine was created before MLIR had a proper pass management infrastructure or an LLVM IR dialect (using the LLVM target directly). It has been running a bunch of lowering passes to convert the input IR from Standard+Affine dialects to LLVM IR and, later, to the LLVM IR dialect. This is no longer necessary and is even undesirable for compilation flows that perform their own conversion to the LLVM IR dialect. Drop this integration and make ExecutionEngine accept only the LLVM IR dialect. Users of the ExecutionEngine can call the relevant passes themselves. -- PiperOrigin-RevId: 249004676
OpenPOWER on IntegriCloud