summaryrefslogtreecommitdiffstats
path: root/mlir/lib/Transforms/CSE.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Adjust License.txt file to use the LLVM licenseMehdi Amini2019-12-231-13/+4
| | | | PiperOrigin-RevId: 286906740
* Add support for instance specific pass statistics.River Riddle2019-12-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CSE] NFC: Hash the attribute dictionary pointer instead of the list of ↵River Riddle2019-12-041-2/+2
| | | | | | attributes. PiperOrigin-RevId: 283810829
* Convert the Canonicalize and CSE passes to generic Operation Passes.River Riddle2019-10-241-11/+10
| | | | | | This allows for them to be used on other non-function, or even other function-like, operations. The algorithms are already generic, so this is simply changing the derived pass type. The majority of this change is just ensuring that the nesting of these passes remains the same, as the pass manager won't auto-nest them anymore. PiperOrigin-RevId: 276573038
* NFC: Finish replacing FunctionPassBase/ModulePassBase with OpPassBase.River Riddle2019-09-131-1/+1
| | | | | | These directives were temporary during the generalization of FunctionPass/ModulePass to OpPass. PiperOrigin-RevId: 268970259
* Change from llvm::make_unique to std::make_uniqueJacques Pienaar2019-08-171-3/+3
| | | | | | | | 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
* Express ownership transfer in PassManager API through std::unique_ptr (NFC)Mehdi Amini2019-08-121-1/+3
| | | | | | | | | | | | | | 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
* Add utility 'replaceAllUsesWith' methods to Operation.River Riddle2019-08-071-2/+1
| | | | | | These methods will allow replacing the uses of results with an existing operation, with the same number of results, or a range of values. This removes a number of hand-rolled result replacement loops and simplifies replacement for operations with multiple results. PiperOrigin-RevId: 262206600
* Update CSE to respect nested regions that are isolated from above. This cl ↵River Riddle2019-06-241-28/+40
| | | | | | also removes the unused 'NthRegionIsIsolatedFromAbove' trait as it was replaced with a more general 'IsIsolatedFromAbove'. PiperOrigin-RevId: 254709704
* Replace usages of Instruction with Operation in the Transforms/ directory.River Riddle2019-03-291-12/+12
| | | | PiperOrigin-RevId: 240636130
* Add experimental support for multi-threading the pass manager. This adds ↵River Riddle2019-03-291-0/+3
| | | | | | 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
* Remove const from Value, Instruction, Argument, and the various methods on theChris Lattner2019-03-291-2/+5
| | | | | | *Op classes. This is a net reduction by almost 400LOC. PiperOrigin-RevId: 239972443
* Remove some statements that required >C++11, add includes and qualify names. ↵Jacques Pienaar2019-03-291-2/+2
| | | | | | NFC. PiperOrigin-RevId: 239197784
* Rename BlockList into RegionAlex Zinenko2019-03-291-15/+14
| | | | | | NFC. This is step 1/n to specifying regions as parts of any operation. PiperOrigin-RevId: 238472370
* NFC: Remove 'Result' from the analysis manager api to better reflect the ↵River Riddle2019-03-291-1/+1
| | | | | | implementation. There is no distinction between analysis computation and result. PiperOrigin-RevId: 237093101
* Add support for preserving specific analyses in the analysis manager. Passes ↵River Riddle2019-03-291-0/+10
| | | | | | | | | | | 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
* Implement the initial AnalysisManagement infrastructure, with the ↵River Riddle2019-03-291-2/+8
| | | | | | | | | | | | | | | | | | 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-4/+2
| | | | | | 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
* Port all of the existing passes over to the new pass manager infrastructure. ↵River Riddle2019-03-291-10/+6
| | | | | | This is largely NFC. PiperOrigin-RevId: 235952357
* Rewrite the dominance info classes to allow for operating on arbitrary ↵River Riddle2019-03-291-14/+27
| | | | | | control flow within operation regions. The CSE pass is also updated to properly handle nested dominance. PiperOrigin-RevId: 235742627
* Define a PassID class to use when defining a pass. This allows for the type ↵River Riddle2019-03-291-3/+1
| | | | | | 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-291-1/+1
| | | | | | | * PassRegistry is split into its own source file. * Pass related files are moved to a new library 'Pass'. PiperOrigin-RevId: 234705771
* Remove InstWalker and move all instruction walking to the api facilities on ↵River Riddle2019-03-291-1/+0
| | | | | | Function/Block/Instruction. PiperOrigin-RevId: 232388113
* Remove remaining usages of OperationInst in lib/Transforms.River Riddle2019-03-291-25/+18
| | | | PiperOrigin-RevId: 232323671
* Define the AffineForOp and replace ForInst with it. This patch is largely ↵River Riddle2019-03-291-5/+0
| | | | | | mechanical, i.e. changing usages of ForInst to OpPointer<AffineForOp>. An important difference is that upon construction an AffineForOp no longer automatically creates the body and induction variable. To generate the body/iv, 'createBody' can be called on an AffineForOp with no body. PiperOrigin-RevId: 232060516
* Recommit: Define a AffineOps dialect as well as an AffineIfOp operation. ↵River Riddle2019-03-291-10/+0
| | | | | | Replace all instances of IfInst with AffineIfOp and delete IfInst. PiperOrigin-RevId: 231342063
* Automated rollback of changelist 231318632.Nicolas Vasilache2019-03-291-0/+10
| | | | PiperOrigin-RevId: 231327161
* Define a AffineOps dialect as well as an AffineIfOp operation. Replace all ↵River Riddle2019-03-291-10/+0
| | | | | | instances of IfInst with AffineIfOp and delete IfInst. PiperOrigin-RevId: 231318632
* Allow operations to hold a blocklist and add support for parsing/printing a ↵River Riddle2019-03-291-10/+26
| | | | | | block list for verbose printing. PiperOrigin-RevId: 230951462
* Merge together the CFG/ML function paths in the CSE pass. I did a first passChris Lattner2019-03-291-126/+113
| | | | | | | | | on this to merge together the classes, but there may be other simplification possible. I'll leave that to riverriddle@ as future work. This is step 29/n towards merging instructions and statements. PiperOrigin-RevId: 227328680
* Standardize naming of statements -> instructions, revisting the code base to beChris Lattner2019-03-291-7/+7
| | | | | | | | | consistent and moving the using declarations over. Hopefully this is the last truly massive patch in this refactoring. This is step 21/n towards merging instructions and statements, NFC. PiperOrigin-RevId: 227178245
* Rename BasicBlock and StmtBlock to Block, and make a pass cleaning it up. I ↵Chris Lattner2019-03-291-2/+2
| | | | | | | | | | | did not make an effort to rename all of the 'bb' names in the codebase, since they are still correct and any specific missed once can be fixed up on demand. The last major renaming is Statement -> Instruction, which is why Statement and Stmt still appears in various places. This is step 19/n towards merging instructions and statements, NFC. PiperOrigin-RevId: 227163082
* Eliminate the using decls for MLFunction and CFGFunction standardizing onChris Lattner2019-03-291-6/+6
| | | | | | | | Function. This is step 18/n towards merging instructions and statements, NFC. PiperOrigin-RevId: 227139399
* Merge Operation into OperationInst and standardize nomenclature aroundChris Lattner2019-03-291-9/+9
| | | | | | | | OperationInst. This is a big mechanical patch. This is step 16/n towards merging instructions and statements, NFC. PiperOrigin-RevId: 227093712
* Eliminate the Instruction, BasicBlock, CFGFunction, MLFunction, and ↵Chris Lattner2019-03-291-2/+3
| | | | | | | | | | | | ExtFunction classes, using the Statement/StmtBlock hierarchy and Function instead. This *only* changes the internal data structures, it does not affect the user visible syntax or structure of MLIR code. Function gets new "isCFG()" sorts of predicates as a transitional measure. This patch is gross in a number of ways, largely in an effort to reduce the amount of mechanical churn in one go. It introduces a bunch of using decls to keep the old names alive for now, and a bunch of stuff needs to be renamed. This is step 10/n towards merging instructions and statements, NFC. PiperOrigin-RevId: 227044402
* Add a simple common sub expression elimination pass.River Riddle2019-03-291-0/+246
The algorithm collects defining operations within a scoped hash table. The scopes within the hash table correspond to nodes within the dominance tree for a function. This cl only adds support for simple operations, i.e non side-effecting. Such operations, e.g. load/store/call, will be handled in later patches. PiperOrigin-RevId: 223811328
OpenPOWER on IntegriCloud