summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Pass
Commit message (Collapse)AuthorAgeFilesLines
* Make helper functions static or move them into anonymous namespaces. NFC.Benjamin Kramer2020-01-141-1/+1
|
* Refactor the way that pass options are specified.River Riddle2019-12-232-10/+66
| | | | | | | | | This change refactors pass options to be more similar to how statistics are modeled. More specifically, the options are specified directly on the pass instead of in a separate options class. (Note that the behavior and specification for pass pipelines remains the same.) This brings about several benefits: * The specification of options is much simpler * The round-trip format of a pass can be generated automatically * This gives a somewhat deeper integration with "configuring" a pass, which we could potentially expose to users in the future. PiperOrigin-RevId: 286953824
* NFC: Replace ValuePtr with Value and remove it now that Value is value-typed.River Riddle2019-12-231-2/+2
| | | | | | ValuePtr was a temporary typedef during the transition to a value-typed Value. PiperOrigin-RevId: 286945714
* Adjust License.txt file to use the LLVM licenseMehdi Amini2019-12-237-91/+28
| | | | PiperOrigin-RevId: 286906740
* NFC: Introduce new ValuePtr/ValueRef typedefs to simplify the transition to ↵River Riddle2019-12-221-2/+2
| | | | | | | | | | Value being value-typed. This is an initial step to refactoring the representation of OpResult as proposed in: https://groups.google.com/a/tensorflow.org/g/mlir/c/XXzzKhqqF_0/m/v6bKb08WCgAJ This change will make it much simpler to incrementally transition all of the existing code to use value-typed semantics. PiperOrigin-RevId: 286844725
* NFC: Remove unnecessary 'llvm::' prefix from uses of llvm symbols declared ↵River Riddle2019-12-185-17/+15
| | | | | | | | in `mlir` namespace. Aside from being cleaner, this also makes the codebase more consistent. PiperOrigin-RevId: 286206974
* Minor spelling tweaksKazuaki Ishizaki2019-12-092-2/+2
| | | | | | Closes tensorflow/mlir#304 PiperOrigin-RevId: 284568358
* Add a flag to the IRPrinter instrumentation to only print after a pass if ↵River Riddle2019-12-062-9/+99
| | | | | | | | there is a change to the IR. This adds an additional filtering mode for printing after a pass that checks to see if the pass actually changed the IR before printing it. This "change" detection is implemented using a SHA1 hash of the current operation and its children. PiperOrigin-RevId: 284291089
* minor spelling tweaksKazuaki Ishizaki2019-12-061-1/+1
| | | | | | | Closes tensorflow/mlir#290 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/290 from kiszk:spelling_tweaks_201912 9d9afd16a723dd65754a04698b3976f150a6054a PiperOrigin-RevId: 284169681
* Refactor the IRPrinting instrumentation to take a derivable config.River Riddle2019-12-052-48/+104
| | | | | | This allows for more interesting behavior from users, e.g. enabling the ability to dump the IR to a separate file for each pass invocation. PiperOrigin-RevId: 284059447
* Add support for instance specific pass statistics.River Riddle2019-12-055-23/+324
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Statistics are a way to keep track of what the compiler is doing and how effective various optimizations are. It is useful to see what optimizations are contributing to making a particular program run faster. Pass-instance specific statistics take this even further as you can see the effect of placing a particular pass at specific places within the pass pipeline, e.g. they could help answer questions like "what happens if I run CSE again here". Statistics can be added to a pass by simply adding members of type 'Pass::Statistics'. This class takes as a constructor arguments: the parent pass pointer, a name, and a description. Statistics can be dumped by the pass manager in a similar manner to how pass timing information is dumped, i.e. via PassManager::enableStatistics programmatically; or -pass-statistics and -pass-statistics-display via the command line pass manager options. Below is an example: struct MyPass : public OperationPass<MyPass> { Statistic testStat{this, "testStat", "A test statistic"}; void runOnOperation() { ... ++testStat; ... } }; $ mlir-opt -pass-pipeline='func(my-pass,my-pass)' foo.mlir -pass-statistics Pipeline Display: ===-------------------------------------------------------------------------=== ... Pass statistics report ... ===-------------------------------------------------------------------------=== 'func' Pipeline MyPass (S) 15 testStat - A test statistic MyPass (S) 6 testStat - A test statistic List Display: ===-------------------------------------------------------------------------=== ... Pass statistics report ... ===-------------------------------------------------------------------------=== MyPass (S) 21 testStat - A test statistic PiperOrigin-RevId: 284022014
* Make diagnostic a bit clearer.Sean Silva2019-12-031-1/+1
| | | | | | This prints out in case of any pass failure. Not just a crash. PiperOrigin-RevId: 283616719
* Add a printer flag to use local scope when printing IR.River Riddle2019-11-121-1/+1
| | | | | | This causes the AsmPrinter to use a local value numbering when printing the IR, allowing for the printer to be used safely in a local context, e.g. to ensure thread-safety when printing the IR. This means that the IR printing instrumentation can also be used during multi-threading when module-scope is disabled. Operation::dump and DiagnosticArgument(Operation*) are also updated to always print local scope, as this is the most common use case when debugging. PiperOrigin-RevId: 279988203
* Fix minor spelling tweaks (NFC)Kazuaki Ishizaki2019-10-202-4/+4
| | | | | | Closes tensorflow/mlir#177 PiperOrigin-RevId: 275692653
* NFC: Print the generic op form after pass failure.River Riddle2019-10-101-8/+9
| | | | | | On failure, the IR is likely to be in an invalid state, meaning the custom printer for some operations may now crash. Using the generic op form prevents this from happening. PiperOrigin-RevId: 274104146
* Add support for generating reproducers on pass crash and failure.River Riddle2019-10-102-2/+100
| | | | | | | | | | | | | | | This cl adds support for generating a .mlir file containing a reproducer for crashes and failures that happen during pass execution. The reproducer contains a comment detailing the configuration of the pass manager(e.g. the textual description of the pass pipeline that the pass manager was executing), along with the original input module. Example Output: // configuration: -pass-pipeline='func(cse, canonicalize), inline' // note: verifyPasses=false module { ... } PiperOrigin-RevId: 274088134
* NFC: Initialize pass manager option fields inline instead of the class ↵River Riddle2019-10-101-51/+31
| | | | | | constructor. PiperOrigin-RevId: 274087577
* Add ::printAsTextualPipeline to Pass and OpPassManager.MLIR Team2019-10-091-0/+23
| | | | | | | | Allow printing out pipelines in a format that is as close as possible to the textual pass pipeline format. Individual passes can override the print function in order to format any options that may have been used to construct that pass. PiperOrigin-RevId: 273813627
* Add Instance Specific Pass Options.MLIR Team2019-10-081-45/+108
| | | | | | | | | | | | | | | | This allows individual passes to define options structs and for these options to be parsed per instance of the pass while building the pass pipeline from the command line provided textual specification. The user can specify these per-instance pipeline options like so: ``` struct MyPassOptions : public PassOptions<MyPassOptions> { Option<int> exampleOption{*this, "flag-name", llvm::cl::desc("...")}; List<int> exampleListOption{*this, "list-flag-name", llvm::cl::desc("...")}; }; static PassRegistration<MyPass, MyPassOptions> pass("my-pass", "description"); ``` PiperOrigin-RevId: 273650140
* Pass the pointer of the parent pipeline collection pass to ↵River Riddle2019-09-302-25/+28
| | | | | | | | PassInstrumentation::run*Pipeline. For the cases where there are multiple levels of nested pass managers, the parent thread ID is not enough to distinguish the parent of a given pass pipeline. Passing in the parent pass gives an exact anchor point. PiperOrigin-RevId: 272105461
* NFC: Fix warning for uninitialized field.River Riddle2019-09-231-1/+3
| | | | PiperOrigin-RevId: 270704572
* Fix a number of Clang-Tidy warnings.Christian Sigg2019-09-232-4/+6
| | | | PiperOrigin-RevId: 270632324
* Update the IRPrinter instrumentation to work on non function/module operations.River Riddle2019-09-142-23/+28
| | | | | | This is necessary now that the pass manager may work on different types of operations. PiperOrigin-RevId: 269139669
* NFC: Pass PassInstrumentations by unique_ptr instead of raw pointer.River Riddle2019-09-143-10/+9
| | | | | | This makes the ownership model explicit, and removes potential user errors. PiperOrigin-RevId: 269122834
* NFC: Merge OpPass with OperationPass into just OperationPass.River Riddle2019-09-141-3/+2
| | | | | | | | | | OperationPass' are defined exactly the same way as they are now: class DerivedPass : public OperationPass<DerivedPass>; OpPass' are now defined as OperationPass, but with an additional template parameter for the operation type: class DerivedPass : public OperationPass<DerivedPass, FuncOp>; PiperOrigin-RevId: 269122410
* Publicly expose the functionality to parse a textual pass pipeline.River Riddle2019-09-131-27/+60
| | | | | | This allows for users other than those on the command line to apply a textual description of a pipeline to a given pass manager. PiperOrigin-RevId: 269017028
* Forward diagnostics from untracked threads in ParallelDiagnosticHandler.River Riddle2019-09-131-0/+6
| | | | | | This allows for the use of multiple ParallelDiagnosticHandlers without having them conflict with each other. PiperOrigin-RevId: 268967407
* Refactor pass pipeline command line parsing to support explicit pipeline ↵River Riddle2019-09-133-29/+313
| | | | | | | | | | | | | | | | strings. This allows for explicitly specifying the pipeline to add to the pass manager. This includes the nesting structure, as well as the passes/pipelines to run. A textual pipeline string is defined as a series of names, each of which may in itself recursively contain a nested pipeline description. A name is either the name of a registered pass, or pass pipeline, (e.g. "cse") or the name of an operation type (e.g. "func"). For example, the following pipeline: $ mlir-opt foo.mlir -cse -canonicalize -lower-to-llvm Could now be specified as: $ mlir-opt foo.mlir -pass-pipeline='func(cse, canonicalize), lower-to-llvm' This will allow for running pipelines on nested operations, like say spirv modules. This does not remove any of the current functionality, and in fact can be used in unison. The new option is available via 'pass-pipeline'. PiperOrigin-RevId: 268954279
* Explicitly declare the OpPassManager move constructor to avoid undefined errors.River Riddle2019-09-091-0/+1
| | | | | | Some compilers will try to auto-generate the destructor, instead of using the user provided destructor, when creating a default move constructor. PiperOrigin-RevId: 268067367
* Add support for coalescing adjacent nested pass pipelines.River Riddle2019-09-093-91/+193
| | | | | | This allows for parallelizing across pipelines of multiple operation types. AdaptorPasses can now hold pass managers for multiple operation types and will dispatch based upon the operation being operated on. PiperOrigin-RevId: 268017344
* Refactor PassTiming to support nested pipelines.River Riddle2019-09-083-77/+187
| | | | | | This is done via a new set of instrumentation hooks runBeforePipeline/runAfterPipeline, that signal the lifetime of a pass pipeline on a specific operation type. These hooks also provide the parent thread of the pipeline, allowing for accurate merging of timers running on different threads. PiperOrigin-RevId: 267909193
* Refactor the pass manager to support operations other than FuncOp/ModuleOp.River Riddle2019-09-024-256/+250
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-48/+13
| | | | | | 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
* Generalize the analysis manager framework to work on any operation at any ↵River Riddle2019-08-282-47/+58
| | | | | | | | nesting. The pass manager is moving towards being able to run on operations at arbitrary nesting. An operation may have both parent and child operations, and the AnalysisManager must be able to handle this generalization. The AnalysisManager class now contains generic 'getCachedParentAnalysis' and 'getChildAnalysis/getCachedChildAnalysis' functions to query analyses on parent/child operations. This removes the hard coded nesting relationship between Module/Function. PiperOrigin-RevId: 266003636
* Change from llvm::make_unique to std::make_uniqueJacques Pienaar2019-08-171-4/+4
| | | | | | | | 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: Refactor the PassInstrumentation framework to operate on Operation ↵River Riddle2019-08-163-45/+38
| | | | | | | | instead of llvm::Any. Now that functions and modules are operations, Operation makes more sense as the opaque object to refer to both. PiperOrigin-RevId: 263883913
* Express ownership transfer in PassManager API through std::unique_ptr (NFC)Mehdi Amini2019-08-122-15/+19
| | | | | | | | | | | | | | 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
* Change the IR printing pass instrumentation to ignore the verifier passes on ↵River Riddle2019-07-123-23/+46
| | | | | | | | non-failure. The verifier passes are NO-OP and are only useful to print after in the case of failure. This removes a lot of unnecessary clutter when printing after/before all passes. PiperOrigin-RevId: 257836310
* NFC: Remove Function::getModule.River Riddle2019-07-122-2/+2
| | | | | | 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-103-6/+6
| | | | | | Module is a legacy name that only exists as a typedef of ModuleOp. PiperOrigin-RevId: 257427248
* NFC: Rename Function to FuncOp.River Riddle2019-07-103-13/+12
| | | | PiperOrigin-RevId: 257293379
* NFC: Remove `Module::getFunctions` in favor of a general `getOps<T>`.River Riddle2019-07-081-2/+2
| | | | | | 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: Make the 'disable-pass-threading' flag a PassManagerOption.River Riddle2019-07-082-8/+25
| | | | | | This also adds the ability to programmatically disable threading. PiperOrigin-RevId: 257051809
* NFC: Move the Function/Module/Operation::verify methods out-of-line.River Riddle2019-07-021-2/+3
| | | | | | 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-023-7/+7
| | | | | | 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-013-19/+18
| | | | | | 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
* Make the ParallelDiagnosticHandler used by the pass manager publicly ↵River Riddle2019-06-011-130/+2
| | | | | | | | available in Diagnostics.h. This provides a common utility for deterministically handling diagnostics in a multi-threaded environment. -- PiperOrigin-RevId: 249325937
* Store the child function analysis maps of a ModuleAnalysisManager by ↵River Riddle2019-05-201-5/+9
| | | | | | | | unique_ptr instead of by-value. -- PiperOrigin-RevId: 248456926
* Change the diagnostic handler to accept Diagnostic instead of ↵River Riddle2019-05-101-46/+39
| | | | | | | | location/message/kind. This opens the door for many more powerful use cases: fixits, colors, etc. -- PiperOrigin-RevId: 247705673
* Replace dyn_cast<> with isa<> when the returned value is unused (NFC)Mehdi Amini2019-05-101-2/+1
| | | | | | | | Fix a gcc warning. -- PiperOrigin-RevId: 247669360
OpenPOWER on IntegriCloud