summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Pass
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove unused PassID member from PassRegistry (NFC)Mehdi Amini2019-05-101-2/+1
| | | | | | | | Fix clang warning -- PiperOrigin-RevId: 247558931
* 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
* Update variable in PassTiming to refer to system_clock instead of ↵River Riddle2019-04-011-1/+1
| | | | | | | | high_resolution_clock. -- PiperOrigin-RevId: 241260071
* Add build files and update README.Jacques Pienaar2019-03-301-0/+9
| | | | | | | | | * Add initial version of build files; * Update README with instructions to download and build MLIR from github; -- PiperOrigin-RevId: 241102092
* [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
* Add support for multi-threaded pass timing.River Riddle2019-03-291-43/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When multi-threading is enabled in the pass manager the meaning of the display slightly changes. First, a new timing column is added, `User Time`, that displays the total time spent across all threads. Secondly, the `Wall Time` column displays the longest individual time spent amongst all of the threads. This means that the `Wall Time` column will continue to give an indicator on the perceived time, or clock time, whereas the `User Time` will display the total cpu time. Example: $ mlir-opt foo.mlir -experimental-mt-pm -cse -canonicalize -convert-to-llvmir -pass-timing ===-------------------------------------------------------------------------=== ... Pass execution timing report ... ===-------------------------------------------------------------------------=== Total Execution Time: 0.0078 seconds ---User Time--- ---Wall Time--- --- Name --- 0.0175 ( 88.3%) 0.0055 ( 70.4%) Function Pipeline 0.0018 ( 9.3%) 0.0006 ( 8.1%) CSE 0.0013 ( 6.3%) 0.0004 ( 5.8%) (A) DominanceInfo 0.0017 ( 8.7%) 0.0006 ( 7.1%) FunctionVerifier 0.0128 ( 64.6%) 0.0039 ( 50.5%) Canonicalizer 0.0011 ( 5.7%) 0.0004 ( 4.7%) FunctionVerifier 0.0004 ( 2.1%) 0.0004 ( 5.2%) ModuleVerifier 0.0010 ( 5.3%) 0.0010 ( 13.4%) LLVMLowering 0.0009 ( 4.3%) 0.0009 ( 11.0%) ModuleVerifier 0.0198 (100.0%) 0.0078 (100.0%) Total PiperOrigin-RevId: 240636269
* 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-293-18/+123
| | | | | | 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
* Continue pushing const out of the core IR types - in this case, remove constChris Lattner2019-03-291-2/+2
| | | | | | from Function. PiperOrigin-RevId: 239638635
* 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
* Moving the IR printing and execution timing options out of mlir-opt and into ↵River Riddle2019-03-291-0/+153
| | | | | | lib/Pass. We now expose two methods: registerPassManagerCLOptions and applyPassManagerCLOptions; to allow for multiple different users (mlir-opt, etc.) to opt-in to this common functionality. PiperOrigin-RevId: 238836911
* Replace the usages of llvm::Timer in PassTiming in favor of a simple nested ↵River Riddle2019-03-291-187/+173
| | | | | | Timer. The output view is simplified to just display the Wall Time. This new infrastructure will greatly simplify the amount of work needed to support multi-threaded execution timing. PiperOrigin-RevId: 238819218
* Add an instrumentation for conditionally printing the IR before and after ↵River Riddle2019-03-294-8/+140
| | | | | | | | | | | | | | | | | pass execution. This instrumentation can be added directly to the PassManager via 'enableIRPrinting'. mlir-opt exposes access to this instrumentation via the following flags: * print-ir-before=(comma-separated-pass-list) - Print the IR before each of the passes provided within the pass list. * print-ir-before-all - Print the IR before every pass in the pipeline. * print-ir-after=(comma-separated-pass-list) - Print the IR after each of the passes provided within the pass list. * print-ir-after-all - Print the IR after every pass in the pipeline. * print-ir-module-scope - Always print the Module IR, even for non module passes. PiperOrigin-RevId: 238523649
* Refactor pass timing so that it is toggled on the passmanager via ↵River Riddle2019-03-292-12/+84
| | | | | | 'enableTiming'. This also makes the pipeline view the default display mode. PiperOrigin-RevId: 238079916
* Add a new instrumentation for timing pass and analysis execution. This is ↵River Riddle2019-03-291-0/+234
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | made available in mlir-opt via the 'pass-timing' and 'pass-timing-display' flags. The 'pass-timing-display' flag toggles between the different available display modes for the timing results. The current display modes are 'list' and 'pipeline', with 'list' representing the default. Below shows the output for an example mlir-opt command line. mlir-opt foo.mlir -verify-each=false -cse -canonicalize -cse -cse -pass-timing list view (-pass-timing-display=list): * In this mode the results are displayed in a list sorted by total time; with each pass/analysis instance aggregated into one unique result. This mode is similar to the output of 'time-passes' in llvm-opt. ===-------------------------------------------------------------------------=== ... Pass execution timing report ... ===-------------------------------------------------------------------------=== Total Execution Time: 0.0097 seconds (0.0096 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 0.0051 ( 58.3%) 0.0001 ( 12.2%) 0.0052 ( 53.8%) 0.0052 ( 53.8%) Canonicalizer 0.0025 ( 29.1%) 0.0005 ( 58.2%) 0.0031 ( 31.9%) 0.0031 ( 32.0%) CSE 0.0011 ( 12.6%) 0.0003 ( 29.7%) 0.0014 ( 14.3%) 0.0014 ( 14.2%) DominanceInfo 0.0087 (100.0%) 0.0009 (100.0%) 0.0097 (100.0%) 0.0096 (100.0%) Total pipeline view (-pass-timing-display=pipeline): * In this mode the results are displayed in a nested pipeline view that mirrors the internal pass pipeline that is being executed in the pass manager. This view is useful for understanding specifically which parts of the pipeline are taking the most time, and can also be used to identify when analyses are being invalidated and recomputed. ===-------------------------------------------------------------------------=== ... Pass execution timing report ... ===-------------------------------------------------------------------------=== Total Execution Time: 0.0082 seconds (0.0081 wall clock) ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 0.0042 (100.0%) 0.0039 (100.0%) 0.0082 (100.0%) 0.0081 (100.0%) Function Pipeline 0.0005 ( 11.6%) 0.0008 ( 21.1%) 0.0013 ( 16.1%) 0.0013 ( 16.2%) CSE 0.0002 ( 5.0%) 0.0004 ( 9.3%) 0.0006 ( 7.0%) 0.0006 ( 7.0%) (A) DominanceInfo 0.0026 ( 61.8%) 0.0018 ( 45.6%) 0.0044 ( 54.0%) 0.0044 ( 54.1%) Canonicalizer 0.0005 ( 11.7%) 0.0005 ( 13.0%) 0.0010 ( 12.3%) 0.0010 ( 12.4%) CSE 0.0003 ( 6.1%) 0.0003 ( 8.3%) 0.0006 ( 7.2%) 0.0006 ( 7.1%) (A) DominanceInfo 0.0002 ( 3.8%) 0.0001 ( 2.8%) 0.0003 ( 3.3%) 0.0003 ( 3.3%) CSE 0.0042 (100.0%) 0.0039 (100.0%) 0.0082 (100.0%) 0.0081 (100.0%) Total PiperOrigin-RevId: 237825367
* NFC: Move the PassExecutor and PassAdaptor classes into PassDetail.h so that ↵River Riddle2019-03-292-95/+131
| | | | | | they can be referenced throughout lib/Pass. PiperOrigin-RevId: 237712736
* Move the success/failure functions out of LogicalResult and into the mlir ↵River Riddle2019-03-291-6/+6
| | | | | | namespace. PiperOrigin-RevId: 237712180
* Add basic infrastructure for instrumenting pass execution and analysis ↵River Riddle2019-03-291-8/+48
| | | | | | | | | | | | computation. A virtual class, PassInstrumentation, is provided to allow for different parts of the pass manager infrastructure. The currently available hooks allow for instrumenting: * before/after pass execution * after a pass fails * before/after an analysis is computed After getting this infrastructure in place, we can start providing common developer utilities like pass timing, IR printing after pass execution, etc. PiperOrigin-RevId: 237709692
* Rename Status to LogicalResult to avoid conflictions with the Status in ↵River Riddle2019-03-291-17/+18
| | | | | | xla/tensorflow/etc. PiperOrigin-RevId: 237537341
* Update the PassManager infrastructure to return Status instead of bool.River Riddle2019-03-291-26/+24
| | | | PiperOrigin-RevId: 237261205
* Add support for preserving specific analyses in the analysis manager. Passes ↵River Riddle2019-03-291-3/+14
| | | | | | | | | | | can now preserve specific analyses via 'markAnalysesPreserved'. Example: markAnalysesPreserved<DominanceInfo>(); markAnalysesPreserved<DominanceInfo, PostDominanceInfo>(); PiperOrigin-RevId: 237081454
* Change Pass:getFunction() to return pointer instead of ref - NFCUday Bondhugula2019-03-291-1/+1
| | | | | | | | | - change this for consistency - everything else similar takes/returns a Function pointer - the FuncBuilder ctor, Block/Value/Instruction::getFunction(), etc. - saves a whole bunch of &s everywhere PiperOrigin-RevId: 236928761
* Add a 'verifyPasses' flag to the PassManager that specifies if the IR should ↵River Riddle2019-03-291-13/+35
| | | | | | be verified after each pass. This also adds a "verify-each" flag to mlir-opt to optionally disable running the verifier after each pass. PiperOrigin-RevId: 236703760
* Implement the initial AnalysisManagement infrastructure, with the ↵River Riddle2019-03-291-19/+59
| | | | | | | | | | | | | | | | | | introduction of the FunctionAnalysisManager and ModuleAnalysisManager classes. These classes provide analysis computation, caching, and invalidation for a specific IR unit. The invalidation is currently limited to either all or none, i.e. you cannot yet preserve specific analyses. An analysis can be any class, but it must provide the following: * A constructor for a given IR unit. struct MyAnalysis { // Compute this analysis with the provided module. MyAnalysis(Module *module); }; Analyses can be accessed from a Pass by calling either the 'getAnalysisResult<AnalysisT>' or 'getCachedAnalysisResult<AnalysisT>' methods. A FunctionPass may query for a cached analysis on the parent module with 'getCachedModuleAnalysisResult'. Similary, a ModulePass may query an analysis, it doesn't need to be cached, on a child function with 'getFunctionAnalysisResult'. By default, when running a pass all cached analyses are set to be invalidated. If no transformation was performed, a pass can use the method 'markAllAnalysesPreserved' to preserve all analysis results. As noted above, preserving specific analyses is not yet supported. PiperOrigin-RevId: 236505642
* Remove PassResult and have the runOnFunction/runOnModule functions return ↵River Riddle2019-03-291-21/+31
| | | | | | void instead. To signal a pass failure, passes should now invoke the 'signalPassFailure' method. This provides the equivalent functionality when needed, but isn't an intrusive part of the API like PassResult. PiperOrigin-RevId: 236202029
* Move the PassExecutor and ModuleToFunctionPassAdaptor classes from ↵River Riddle2019-03-291-1/+159
| | | | | | PassManager.h to Pass.cpp. This allows for us to remove a dependency on Pass.h from PassManager.h. PiperOrigin-RevId: 236029339
* Add support for registering pass pipelines to the PassRegistry. This is done ↵River Riddle2019-03-291-6/+54
| | | | | | | | | | | | | | | | | | | by providing a static registration facility PassPipelineRegistration that works similarly to PassRegistration except for it also takes a function that will add necessary passes to a provided PassManager. void pipelineBuilder(PassManager &pm) { pm.addPass(new MyPass()); pm.addPass(new MyOtherPass()); } static PassPipelineRegistration Unused("unused", "Unused pass", pipelineBuilder); This is also useful for registering specializations of existing passes: Pass *createFooPass10() { return new FooPass(10); } static PassPipelineRegistration Unused("unused", "Unused pass", createFooPass10); PiperOrigin-RevId: 235996282
* Port all of the existing passes over to the new pass manager infrastructure. ↵River Riddle2019-03-291-18/+0
| | | | | | This is largely NFC. PiperOrigin-RevId: 235952357
* Implement the initial pass management functionality.River Riddle2019-03-291-0/+59
| | | | | | | | | | | | | | | | The definitions of derived passes have now changed and passes must adhere to the following: * Inherit from a CRTP base class FunctionPass/ModulePass. - This class provides several necessary utilities for the transformation: . Access to the IR unit being transformed (getFunction/getModule) . Various utilities for pass identification and registration. * Provide a 'PassResult runOn(Function|Module)()' method to transform the IR. - This replaces the runOn* functions from before. This patch also introduces the notion of the PassManager. This allows for simplified construction of pass pipelines and acts as the sole interface for executing passes. This is important as FunctionPass will no longer have a 'runOnModule' method. PiperOrigin-RevId: 235952008
* Add a Function::isExternal utility to simplify checks for external functions.River Riddle2019-03-291-1/+1
| | | | PiperOrigin-RevId: 235746553
* Define a PassID class to use when defining a pass. This allows for the type ↵River Riddle2019-03-291-3/+4
| | | | | | used for the ID field to be self documenting. It also allows for the compiler to know the set alignment of the ID object, which is useful for storing pointer identifiers within llvm data structures. PiperOrigin-RevId: 235107957
* NFC: Refactor the files related to passes.River Riddle2019-03-292-0/+112
* PassRegistry is split into its own source file. * Pass related files are moved to a new library 'Pass'. PiperOrigin-RevId: 234705771
OpenPOWER on IntegriCloud