summaryrefslogtreecommitdiffstats
path: root/mlir/examples
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix a number of Clang-Tidy warnings.Christian Sigg2019-09-232-2/+2
| | | | PiperOrigin-RevId: 270632324
* NFC: Pass OpAsmPrinter by reference instead of by pointer.River Riddle2019-09-2011-48/+48
| | | | | | MLIR follows the LLVM style of pass-by-reference. PiperOrigin-RevId: 270401378
* NFC: Pass OperationState by reference instead of by pointer.River Riddle2019-09-2017-178/+178
| | | | | | MLIR follows the LLVM convention of passing by reference instead of by pointer. PiperOrigin-RevId: 270396945
* NFC: Pass OpAsmParser by reference instead of by pointer.River Riddle2019-09-2011-59/+58
| | | | | | MLIR follows the LLVM style of pass-by-reference. PiperOrigin-RevId: 270315612
* Unify error messages to start with lower-case.MLIR Team2019-09-1810-36/+36
| | | | PiperOrigin-RevId: 269803466
* Drop makePositionAttr and the like in favor of Builder::getI64ArrayAttrAlex Zinenko2019-09-162-29/+9
| | | | | | | | | | The helper functions makePositionAttr() and positionAttr() were originally introduced in the lowering-to-LLVM-dialect pass to construct integer array attributes that are used for static positions in extract/insertelement. Constructing an integer array attribute being fairly common, a utility function Builder::getI64ArrayAttr was later introduced into the Builder API. Drop makePositionAttr and similar homegrown functions and use that API instead. PiperOrigin-RevId: 269295836
* Add pattern to canonicalize for loop boundsUday Bondhugula2019-09-132-20/+20
| | | | | | | | | | | | | | - add pattern to canonicalize affine.for loop bounds (using canonicalizeMapAndOperands) - rename AffineForLoopBoundFolder -> AffineForLoopBoundFolder for consistency Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#111 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/111 from bondhugula:bound-canonicalize ee8fb7f43a7ffd45f6df3f53c95098d8b7e494c7 PiperOrigin-RevId: 269041220
* NFC: Finish replacing FunctionPassBase/ModulePassBase with OpPassBase.River Riddle2019-09-134-6/+5
| | | | | | These directives were temporary during the generalization of FunctionPass/ModulePass to OpPass. PiperOrigin-RevId: 268970259
* Refactor the pass manager to support operations other than FuncOp/ModuleOp.River Riddle2019-09-025-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change generalizes the structure of the pass manager to allow arbitrary nesting pass managers for other operations, at any level. The only user visible change to existing code is the fact that a PassManager must now provide an MLIRContext on construction. A new class `OpPassManager` has been added that represents a pass manager on a specific operation type. `PassManager` will remain the top-level entry point into the pipeline, with OpPassManagers being nested underneath. OpPassManagers will still be implicitly nested if the operation type on the pass differs from the pass manager. To explicitly build a pipeline, the 'nest' methods on OpPassManager may be used: // Pass manager for the top-level module. PassManager pm(ctx); // Nest a pipeline operating on FuncOp. OpPassManager &fpm = pm.nest<FuncOp>(); fpm.addPass(...); // Nest a pipeline under the FuncOp pipeline that operates on spirv::ModuleOp OpPassManager &spvModulePM = pm.nest<spirv::ModuleOp>(); // Nest a pipeline on FuncOps inside of the spirv::ModuleOp. OpPassManager &spvFuncPM = spvModulePM.nest<FuncOp>(); To help accomplish this a new general OperationPass is added that operates on opaque Operations. This pass can be inserted in a pass manager of any type to operate on any operation opaquely. An example of this opaque OperationPass is a VerifierPass, that simply runs the verifier opaquely on the current operation. /// Pass to verify an operation and signal failure if necessary. class VerifierPass : public OperationPass<VerifierPass> { void runOnOperation() override { Operation *op = getOperation(); if (failed(verify(op))) signalPassFailure(); markAllAnalysesPreserved(); } }; PiperOrigin-RevId: 266840344
* Generalize the pass hierarchy by adding a general OpPass<PassT, OpT>.River Riddle2019-08-302-2/+6
| | | | | | This pass class generalizes the current functionality between FunctionPass and ModulePass, and allows for operating on any operation type. The pass manager currently only supports OpPasses operating on FuncOp and ModuleOp, but this restriction will be relaxed in follow-up changes. A utility class OpPassBase<OpT> allows for generically referring to operation specific passes: e.g. FunctionPassBase == OpPassBase<FuncOp>. PiperOrigin-RevId: 266442239
* Refactor the 'walk' methods for operations.River Riddle2019-08-292-2/+2
| | | | | | | | | | | | This change refactors and cleans up the implementation of the operation walk methods. After this refactoring is that the explicit template parameter for the operation type is no longer needed for the explicit op walks. For example: op->walk<AffineForOp>([](AffineForOp op) { ... }); is now accomplished via: op->walk([](AffineForOp op) { ... }); PiperOrigin-RevId: 266209552
* Extend map canonicalization to propagate constant operandsUday Bondhugula2019-08-291-2/+2
| | | | | | | | | | | | | | | | | | | - extend canonicalizeMapAndOperands to propagate constant operands into the map's expressions (and thus drop those operands). - canonicalizeMapAndOperands previously only dropped duplicate and unused operands; however, operands that were constants were retained. This change makes IR maps/expressions generated by various utilities/passes even simpler; also makes some of the test checks more accurate and simpler -- for eg., 0' instead of symbol(%{{.*}}). Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#107 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/107 from bondhugula:canonicalize-maps c889a51486d14fbf7db489f224f881e7e1ff7d72 PiperOrigin-RevId: 266085289
* Update Ch.2 of the Toy tutorial.River Riddle2019-08-275-223/+207
| | | | | | | | The code and documentation for this chapter of the tutorial have been updated to follow the new flow. The toy 'array' type has been replaced by usages of the MLIR tensor type. The code has also been cleaned up and modernized. Closes tensorflow/mlir#101 PiperOrigin-RevId: 265744086
* 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 AffineOps dialect to the Dialect sub-directory.River Riddle2019-08-202-2/+2
| | | | PiperOrigin-RevId: 264482571
* NFC: Move LLVMIR, SDBM, and StandardOps to the Dialect/ directory.River Riddle2019-08-1913-13/+13
| | | | PiperOrigin-RevId: 264193915
* Change from llvm::make_unique to std::make_uniqueJacques Pienaar2019-08-1714-118/+108
| | | | | | | | 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-1211-11/+25
| | | | | | | | | | | | | | 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-095-8/+6
| | | | | | 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
* Refactor Linalg ops to loop lowering (NFC)Nicolas Vasilache2019-08-062-3/+3
| | | | | | | This CL modifies the LowerLinalgToLoopsPass to use RewritePattern. This will make it easier to inline Linalg generic functions and regions when emitting to loops in a subsequent CL. PiperOrigin-RevId: 261894120
* 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-058-18/+17
| | | | | | 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
* Update style/clang-format (NFC).Jacques Pienaar2019-07-221-1/+1
| | | | | | Update to be consistent & so that future save + clang-format workflows don't introduce extra changes. PiperOrigin-RevId: 259361174
* Refactor region type signature conversion to be explicit via patterns.River Riddle2019-07-203-2/+11
| | | | | | 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-194-26/+38
| | | | | | 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-193-4/+6
| | | | | | | | 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-164-8/+7
| | | | | | | | | | | 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 lowerAffineConstructs and lowerControlFlow in favor of providing ↵River Riddle2019-07-162-20/+6
| | | | | | | | patterns. These methods don't compose well with the rest of conversion framework, and create artificial breaks in conversion. Replace these methods with two(populateAffineToStdConversionPatterns and populateLoopToStdConversionPatterns respectively) that populate a list of patterns to perform the same behavior. PiperOrigin-RevId: 258219277
* 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
* Lower affine control flow to std control flow to LLVM dialectNicolas Vasilache2019-07-127-24/+40
| | | | | | | | | | | | | This CL splits the lowering of affine to LLVM into 2 parts: 1. affine -> std 2. std -> LLVM The conversions mostly consists of splitting concerns between the affine and non-affine worlds from existing conversions. Short-circuiting of affine `if` conditions was never tested or exercised and is removed in the process, it can be reintroduced later if needed. LoopParametricTiling.cpp is updated to reflect the newly added ForOp::build. PiperOrigin-RevId: 257794436
* 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: Remove Function::getModule.River Riddle2019-07-123-4/+4
| | | | | | There is already a more general 'getParentOfType' method, and 'getModule' is likely to be misused as functions get placed within different regions than ModuleOp. PiperOrigin-RevId: 257442243
* NFC: Rename Module to ModuleOp.River Riddle2019-07-1017-33/+31
| | | | | | 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-109-16/+16
| | | | | | This allows for giving a Module a more interesting location than 'Unknown'. PiperOrigin-RevId: 257310117
* NFC: Rename Function to FuncOp.River Riddle2019-07-1017-76/+74
| | | | PiperOrigin-RevId: 257293379
* Standardize the value numbering in the AsmPrinter.River Riddle2019-07-092-112/+112
| | | | | | Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations. PiperOrigin-RevId: 257225069
* NFC: Remove `Module::getFunctions` in favor of a general `getOps<T>`.River Riddle2019-07-084-6/+8
| | | | | | 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-035-7/+12
| | | | | | 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-0211-13/+24
| | | | | | 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-0225-91/+87
| | | | | | 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-0118-214/+221
| | | | | | 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
OpenPOWER on IntegriCloud