summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Pass/Pass.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Refactor the way that pass options are specified.River Riddle2019-12-231-3/+17
| | | | | | | | | 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
* Adjust License.txt file to use the LLVM licenseMehdi Amini2019-12-231-13/+4
| | | | PiperOrigin-RevId: 286906740
* NFC: Remove unnecessary 'llvm::' prefix from uses of llvm symbols declared ↵River Riddle2019-12-181-2/+2
| | | | | | | | in `mlir` namespace. Aside from being cleaner, this also makes the codebase more consistent. PiperOrigin-RevId: 286206974
* Minor spelling tweaksKazuaki Ishizaki2019-12-091-1/+1
| | | | | | Closes tensorflow/mlir#304 PiperOrigin-RevId: 284568358
* Add support for instance specific pass statistics.River Riddle2019-12-051-3/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix minor spelling tweaks (NFC)Kazuaki Ishizaki2019-10-201-1/+1
| | | | | | Closes tensorflow/mlir#177 PiperOrigin-RevId: 275692653
* Add support for generating reproducers on pass crash and failure.River Riddle2019-10-101-2/+88
| | | | | | | | | | | | | | | 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
* 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
* Pass the pointer of the parent pipeline collection pass to ↵River Riddle2019-09-301-13/+17
| | | | | | | | 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
* Fix a number of Clang-Tidy warnings.Christian Sigg2019-09-231-1/+2
| | | | PiperOrigin-RevId: 270632324
* NFC: Pass PassInstrumentations by unique_ptr instead of raw pointer.River Riddle2019-09-141-8/+7
| | | | | | 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
* 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-131-10/+4
| | | | | | | | | | | | | | | | 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-091-64/+155
| | | | | | 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-081-4/+42
| | | | | | 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-021-133/+204
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-301-46/+11
| | | | | | 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-281-45/+56
| | | | | | | | 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-161-10/+10
| | | | | | | | 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-121-13/+13
| | | | | | | | | | | | | | 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-121-21/+17
| | | | | | | | 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-121-1/+1
| | | | | | 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-101-3/+3
| | | | | | Module is a legacy name that only exists as a typedef of ModuleOp. PiperOrigin-RevId: 257427248
* NFC: Rename Function to FuncOp.River Riddle2019-07-101-8/+7
| | | | 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-081-6/+6
| | | | | | 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-021-3/+3
| | | | | | 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-011-12/+11
| | | | | | 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
* Introduce a new API for emitting diagnostics with Diagnostic and ↵River Riddle2019-05-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | InFlightDiagnostic. The Diagnostic class contains all of the information necessary to report a diagnostic to the DiagnosticEngine. It should generally not be constructed directly, and instead used transitively via InFlightDiagnostic. A diagnostic is currently comprised of several different elements: * A severity level. * A source Location. * A list of DiagnosticArguments that help compose and comprise the output message. * A DiagnosticArgument represents any value that may be part of the diagnostic, e.g. string, integer, Type, Attribute, etc. * Arguments can be added to the diagnostic via the stream(<<) operator. * (In a future cl) A list of attached notes. * These are in the form of other diagnostics that provide supplemental information to the main diagnostic, but do not have context on their own. The InFlightDiagnostic class represents an RAII wrapper around a Diagnostic that is set to be reported with the diagnostic engine. This allows for the user to modify a diagnostic that is inflight. The internally wrapped diagnostic can be reported directly or automatically upon destruction. These classes allow for more natural composition of diagnostics by removing the restriction that the message of a diagnostic is comprised of a single Twine. They should also allow for nice incremental improvements to the diagnostics experience in the future, e.g. formatv style diagnostics. Simple Example: emitError(loc, "integer bitwidth is limited to " + Twine(IntegerType::kMaxWidth) + " bits"); emitError(loc) << "integer bitwidth is limited to " << IntegerType::kMaxWidth << " bits"; -- PiperOrigin-RevId: 246526439
* Add support for basic remark diagnostics. This is the minimal ↵River Riddle2019-05-061-0/+3
| | | | | | | | functionality needed to separate notes from remarks. It also provides a starting point to start building out better remark infrastructure. -- PiperOrigin-RevId: 246175216
* Start sketching out a new diagnostics infrastructure. Create a new class ↵River Riddle2019-05-061-22/+22
| | | | | | | | 'DiagnosticEngine' and move the diagnostic handler support and final diagnostic emission from the MLIRContext to it. -- PiperOrigin-RevId: 246163897
* Enable multi-threading in the pass manager by default.River Riddle2019-05-061-8/+8
| | | | | | -- PiperOrigin-RevId: 245458081
* Update the Function and Module verifiers to return LogicalResult instead ↵River Riddle2019-04-021-2/+2
| | | | | | | | of bool. -- PiperOrigin-RevId: 241553930
* [PassManager] Add a utility class, PrettyStackTraceParallelDiagnosticEntry, ↵River Riddle2019-03-291-2/+62
| | | | | | to emit any queued up diagnostics in the event of a crash when multi-threading. PiperOrigin-RevId: 240986566
* [PassManager] Define a ParallelDiagnosticHandler to ensure that diagnostics ↵River Riddle2019-03-291-0/+80
| | | | | | are still produced in a deterministic order when multi-threading. PiperOrigin-RevId: 240817922
* Initialize std::atomic directly.Jacques Pienaar2019-03-291-2/+2
| | | | | | Avoids error in OSS build: error: copying variable of type 'std::atomic<unsigned int>' invokes deleted constructor PiperOrigin-RevId: 240618765
* Add experimental support for multi-threading the pass manager. This adds ↵River Riddle2019-03-291-5/+90
| | | | | | support for running function pipelines on functions across multiple threads, and is guarded by an off-by-default flag 'experimental-mt-pm'. There are still quite a few things that need to be done before multi-threading is ready for general use(e.g. pass-timing), but this allows for those things to be tested in a multi-threaded environment. PiperOrigin-RevId: 240489002
* Make FunctionPass::getFunction() return a reference to the function, instead ofChris Lattner2019-03-291-1/+1
| | | | | | | a pointer. This makes it consistent with all the other methods in FunctionPass, as well as with ModulePass::getModule(). NFC. PiperOrigin-RevId: 240257910
* Cleanup for changes failing with std=c++11Jacques Pienaar2019-03-291-0/+2
| | | | | | The static constexpr were failing with undefined reference due to lacking definition at namespace scope. PiperOrigin-RevId: 239241157
* Give PassInstrumentor a SmartMutex to lock access to the held instrumentations.River Riddle2019-03-291-0/+64
| | | | PiperOrigin-RevId: 239031524
* Refactor pass timing so that it is toggled on the passmanager via ↵River Riddle2019-03-291-7/+8
| | | | | | 'enableTiming'. This also makes the pipeline view the default display mode. PiperOrigin-RevId: 238079916
* NFC: Move the PassExecutor and PassAdaptor classes into PassDetail.h so that ↵River Riddle2019-03-291-95/+7
| | | | | | they can be referenced throughout lib/Pass. PiperOrigin-RevId: 237712736
OpenPOWER on IntegriCloud