summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/LegacyPassManager.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Recommit r256952 "Filtering IR printing for print-after-all/print-before-all"Weiming Zhao2016-01-061-0/+13
| | | | | | | | Fix lit test fail due to outputting an extra line. Differential Revision: http://reviews.llvm.org/D15776 llvm-svn: 256987
* Revert r256952 due to lit test fails.Weiming Zhao2016-01-061-13/+0
| | | | llvm-svn: 256954
* Filtering IR printing for print-after-all/print-before-allWeiming Zhao2016-01-061-0/+13
| | | | | | | | | | | | | | | Summary: This patch implements "-print-funcs" option to support function filtering for IR printing like -print-after-all, -print-before etc. Examples: -print-after-all -print-funcs=foo,bar Reviewers: mcrosier, joker.eph Subscribers: tejohnson, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D15776 llvm-svn: 256952
* Remove debug output that snuck into 254957Philip Reames2015-12-071-6/+0
| | | | llvm-svn: 254960
* Reapply 254950 w/fixPhilip Reames2015-12-071-0/+6
| | | | | | | | | | | | | | | | | 254950 ended up being not NFC. The previous code was overriding the flags for whether an instruction read or wrote memory using the target specific flags returned via TTI. I'd missed this in my refactoring. Since I mistakenly built only x86 and didn't notice the number of unsupported tests, I didn't catch that before the original checkin. This raises an interesting issue though. Given we have function attributes (i.e. readonly, readnone, argmemonly) which describe the aliasing of intrinsics, why does TTI have this information overriding the instruction definition at all? I see no reason for this, but decided to preserve existing behavior for the moment. The root issue might be that we don't have a "writeonly" attribute. Original commit message: [EarlyCSE] Simplify and invert ParseMemoryInst [NFCI] Restructure ParseMemoryInst - which was introduced to abstract over target specific load and stores instructions - to just query the underlying instructions. In theory, this could be slightly slower than caching the results, but in practice, it's very unlikely to be measurable. The simple query scheme makes it far easier to understand, and much easier to extend with new queries. Given I'm about to need to add new query types, doing the cleanup first seemed worthwhile. Do we still believe the target specific intrinsic handling is worthwhile in EarlyCSE? It adds quite a bit of complexity and makes the code harder to read. Being able to delete the abstraction entirely would be wonderful. llvm-svn: 254957
* [PassManager] Ensure destructors of cached AnalysisUsage objects are runPhilip Reames2015-12-041-1/+1
| | | | | | In 254760, I introduced the usage of a BumpPtrAllocator for the AnalysisUsage instances held by the PassManger. This turns out to have been incorrect since a BumpPtrAllocator does not run the destructors of objects when deallocating memory. Since a few of our SmallVector's had grown beyond their small size, we end up with some leaked memory. We need to use a SpecificBumpPtrAllocator instead. llvm-svn: 254803
* [LegacyPassManager] Reduce memory usage for AnalysisUsagePhilip Reames2015-12-041-8/+24
| | | | | | | | | | The LegacyPassManager was storing an instance of AnalysisUsage for each instance of each pass. In practice, most instances of a single pass class share the same dependencies. We can't rely on this because passes can (and some do) have dynamic dependencies based on instance options. We can exploit the likely commonality by uniqueing the usage information after querying the pass, but before storing it into the pass manager. This greatly reduces memory consumption by the AnalysisUsage objects. For a long pass pipeline, I measured a decrease in memory consumption for this storage of about 50%. I have not measured on the default O3 pipeline, but I suspect it will see some benefit as well since many passes are repeated (e.g. InstCombine). Differential Revision: http://reviews.llvm.org/D14677 llvm-svn: 254760
* Simplify code. No functionality change.Jakub Staszak2015-10-051-9/+2
| | | | llvm-svn: 249335
* [LPM] Simplify this code and fix a compile error for compilers thatChandler Carruth2015-09-101-3/+1
| | | | | | | | don't correctly implement the scoping rules of C++11 range based for loops. This kind of aliasing isn't a good idea anyways (and wasn't really intended). llvm-svn: 247241
* [LPM] Use a map from analysis ID to immutable passes in the legacy passChandler Carruth2015-09-101-18/+24
| | | | | | | | | | | | manager to avoid a slow linear scan of every immutable pass and on every attempt to find an analysis pass. This speeds up 'check-llvm' on an unoptimized build for me by 15%, YMMV. It should also help (a tiny bit) other folks that are really bottlenecked on repeated runs of tiny pass pipelines across small IR files. llvm-svn: 247240
* [LPM] Teach the legacy pass manager to support *using* an analysisChandler Carruth2015-08-191-16/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | without *requiring* it. This allows a pass indicate that it will use an analysis if available (through getAnalysisIfAvailable). When the pass manager knows this, it will refrain from deleting that analysis if it can. Naturally, it will still get invalidated at the correct time. These passes are not considered when scheduling the pass pipeline, so typically they will require manual scheduling, but this may also allow passes with getAnalysisIfAvailable to find the analysis more often if nothing after them requires that analysis and it wasn't invalidated. I don't have a particular use case with the current passes, but with my new structure for alias analyses, this will be very useful. We want to allow people to customize the set of AAs available by scheduling additional passes. These's aren't ever *required* for obvious reasons. So we need some way to mark in the legacy pass manager that they will still be used if available. This is essentially how analysis groups already work. But this makes the feature generally available and more explicit. It should allow the AA change to not impact how people trigger a custom alias analysis being available at a certain point in compilation. Differential Revision: http://reviews.llvm.org/D12114 llvm-svn: 245409
* [LPM] Cleanup some loops to be range based for loops before hacking onChandler Carruth2015-08-181-19/+9
| | | | | | this code. NFC. llvm-svn: 245327
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-231-5/+5
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-5/+5
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
* Rangify more for loops in LegacyPassManager.cpp.Yaron Keren2015-06-051-39/+21
| | | | llvm-svn: 239166
* Rangify for loops in LegacyPassManager.cpp.Yaron Keren2015-06-051-19/+10
| | | | llvm-svn: 239155
* [NFC] Converting to range-based for.Chris Bieneman2015-04-291-2/+1
| | | | llvm-svn: 236163
* Use 'override/final' instead of 'virtual' for overridden methodsAlexander Kornienko2015-04-111-1/+1
| | | | | | | | | | | | | | The patch is generated using clang-tidy misc-use-override check. This command was used: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \ -checks='-*,misc-use-override' -header-filter='llvm|clang' \ -j=32 -fix -format http://reviews.llvm.org/D8925 llvm-svn: 234679
* Typo.Chad Rosier2015-03-201-1/+1
| | | | llvm-svn: 232819
* [LPM] A targeted but somewhat horrible fix to the legacy pass manager'sChandler Carruth2015-01-281-14/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | querying of the pass registry. The pass manager relies on the static registry of PassInfo objects to perform all manner of its functionality. I don't understand why it does much of this. My very vague understanding is that this registry is touched both during static initialization *and* while each pass is being constructed. As a consequence it is hard to make accessing it not require a acquiring some lock. This lock ends up in the hot path of setting up, tearing down, and invaliditing analyses in the legacy pass manager. On most systems you can observe this as a non-trivial % of the time spent in 'ninja check-llvm'. However, I haven't really seen it be more than 1% in extreme cases of compiling more real-world software, including LTO. Unfortunately, some of the GPU JITs are seeing this taking essentially all of their time because they have very small IR running through a small pass pipeline very many times (at least, this is the vague understanding I have of it). This patch tries to minimize the cost of looking up PassInfo objects by leveraging the fact that the objects themselves are immutable and they are allocated separately on the heap and so don't have their address change. It also requires a change I made the last time I tried to debug this problem which removed the ability to de-register a pass from the registry. This patch creates a single access path to these objects inside the PMTopLevelManager which memoizes the result of querying the registry. This is somewhat gross as I don't really know if PMTopLevelManager is the *right* place to put it, and I dislike using a mutable member to memoize things, but it seems to work. For long-lived pass managers this should completely eliminate the cost of acquiring locks to look into the pass registry once the memoized cache is warm. For 'ninja check' I measured about 1.5% reduction in CPU time and in total time on a machine with 32 hardware threads. For normal compilation, I don't know how much this will help, sadly. We will still pay the cost while we populate the memoized cache. I don't think it will hurt though, and for LTO or compiles with many small functions it should still be a win. However, for tight loops around a pass manager with many passes and small modules, this will help tremendously. On the AArch64 backend I saw nearly 50% reductions in time to complete 2000 cycles of spinning up and tearing down the pipeline. Measurements from Owen of an actual long-lived pass manager show more along the lines of 10% improvements. Differential Revision: http://reviews.llvm.org/D7213 llvm-svn: 227299
* Document that PassManager::add() may delete the pass right away.Matthias Braun2014-12-121-17/+2
| | | | | | | | Also remove redundant documentation: - doxygen will copy documentation to overriden methods. - Use \copydoc on PIMPL classes instead of replicating the text. llvm-svn: 224089
* Remove redundant calls to isMaterializable.Rafael Espindola2014-11-011-4/+2
| | | | | | | | | | This removes calls to isMaterializable in the following cases: * It was redundant with a call to isDeclaration now that isDeclaration returns the correct answer for materializable functions. * It was followed by a call to Materialize. Just call Materialize and check EC. llvm-svn: 221050
* Modernize the error handling of the Materialize function.Rafael Espindola2014-10-241-3/+2
| | | | llvm-svn: 220600
* Use range based for loops to avoid needing to re-mention SmallPtrSet size.Craig Topper2014-08-241-3/+2
| | | | llvm-svn: 216351
* Fix typos:Sylvestre Ledru2014-08-111-1/+1
| | | | | | | * libaries => libraries * avaiable => available llvm-svn: 215366
* Add C API for thread yielding callback.Juergen Ributzka2014-05-161-2/+7
| | | | | | | | | | | | | | | | | | | | | Sometimes a LLVM compilation may take more time then a client would like to wait for. The problem is that it is not possible to safely suspend the LLVM thread from the outside. When the timing is bad it might be possible that the LLVM thread holds a global mutex and this would block any progress in any other thread. This commit adds a new yield callback function that can be registered with a context. LLVM will try to yield by calling this callback function, but there is no guaranteed frequency. LLVM will only do so if it can guarantee that suspending the thread won't block any forward progress in other LLVM contexts in the same process. Once the client receives the call back it can suspend the thread safely and resume it at another time. Related to <rdar://problem/16728690> llvm-svn: 208945
* Revert "[PM] Add pass run listeners to the pass manager."Juergen Ributzka2014-05-151-7/+0
| | | | | | | Revert the current implementation and C API. New implementation and C APIs are in the works. llvm-svn: 208904
* [PM] Add pass run listeners to the pass manager.Juergen Ributzka2014-04-281-0/+7
| | | | | | | | | | | | | | | | | | This commit provides the necessary C/C++ APIs and infastructure to enable fine- grain progress report and safe suspension points after each pass in the pass manager. Clients can provide a callback function to the pass manager to call after each pass. This can be used in a variety of ways (progress report, dumping of IR between passes, safe suspension of threads, etc). The run listener list is maintained in the LLVMContext, which allows a multi- threaded client to be only informed for it's own thread. This of course assumes that the client created a LLVMContext for each thread. This fixes <rdar://problem/16728690> llvm-svn: 207430
* Teach the pass manager's execution dump to print the current time beforeChandler Carruth2014-04-271-1/+3
| | | | | | | | | | | | | | | each line. This is particularly nice for tracking which run of a particular pass over a particular function was slow. This also required making the TimeValue string much more useful. First, there is a standard format for writing out a date and time. Let's use that rather than strings that would have to be parsed. Second, actually output the nanosecond resolution that timevalue claims to have. This is proving useful working on PR19499, so I figured it would be generally useful to commit. llvm-svn: 207385
* [C++11] More 'nullptr' conversion or in some cases just using a boolean ↵Craig Topper2014-04-091-16/+16
| | | | | | check instead of comparing to nullptr. llvm-svn: 205831
* Fix a (legacy) PassManager crash that occurs when a ModulePassAndrew Trick2014-04-081-6/+18
| | | | | | | | | indirectly requires a function analysis. This bug was reported by Jason Kim. He included a test case here: http://reviews.llvm.org/D3312 llvm-svn: 205753
* [C++11] Add 'override' keyword to IR library.Craig Topper2014-03-051-30/+33
| | | | llvm-svn: 202939
* [Modules] Move the PassNameParser to the IR library as it deals in theChandler Carruth2014-03-041-1/+1
| | | | | | | PassInfo structures of the legacy pass manager. Also give it the Legacy prefix as it is not a particularly widely used header. llvm-svn: 202839
* Remove unnecessary llvm:: qualification.Eric Christopher2014-02-261-3/+3
| | | | llvm-svn: 202316
* [PM] Simplify the interface exposed for IR printing passes.Chandler Carruth2014-01-121-3/+3
| | | | | | | | | | | | Nothing was using the ability of the pass to delete the raw_ostream it printed to, and nothing was trying to pass it a pointer to the raw_ostream. Also, the function variant had a different order of arguments from all of the others which was just really confusing. Now the interface accepts a reference, doesn't offer to delete it, and uses a consistent order. The implementation of the printing passes haven't been updated with this simplification, this is just the API switch. llvm-svn: 199044
* [PM] Rename the IR printing pass header to a more generic and correctChandler Carruth2014-01-121-1/+1
| | | | | | | | name to match the source file which I got earlier. Update the include sites. Also modernize the comments in the header to use the more recommended doxygen style. llvm-svn: 199041
* Put the functionality for printing a value to a raw_ostream as anChandler Carruth2014-01-091-2/+1
| | | | | | | | | | | | operand into the Value interface just like the core print method is. That gives a more conistent organization to the IR printing interfaces -- they are all attached to the IR objects themselves. Also, update all the users. This removes the 'Writer.h' header which contained only a single function declaration. llvm-svn: 198836
* Move the LLVM IR asm writer header files into the IR directory, as theyChandler Carruth2014-01-071-2/+2
| | | | | | | | | | | | | | | | | are part of the core IR library in order to support dumping and other basic functionality. Rename the 'Assembly' include directory to 'AsmParser' to match the library name and the only functionality left their -- printing has been in the core IR library for quite some time. Update all of the #includes to match. All of this started because I wanted to have the layering in good shape before I started adding support for printing LLVM IR using the new pass infrastructure, and commandline support for the new pass infrastructure. llvm-svn: 198688
* Re-sort all of the includes with ./utils/sort_includes.py so thatChandler Carruth2014-01-071-1/+1
| | | | | | | | | | subsequent changes are easier to review. About to fix some layering issues, and wanted to separate out the necessary churn. Also comment and sink the include of "Windows.h" in three .inc files to match the usage in Memory.inc. llvm-svn: 198685
* Correct word hyphenationsAlp Toker2013-12-051-2/+2
| | | | | | | This patch tries to avoid unrelated changes other than fixing a few hyphen-related ambiguities and contractions in nearby lines. llvm-svn: 196471
* Move the old pass manager infrastructure into a legacy namespace andChandler Carruth2013-11-091-0/+1920
give the files a legacy prefix in the right directory. Use forwarding headers in the old locations to paper over the name change for most clients during the transitional period. No functionality changed here! This is just clearing some space to reduce renaming churn later on with a new system. Even when the new stuff starts to go in, it is going to be hidden behind a flag and off-by-default as it is still WIP and under development. This patch is specifically designed so that very little out-of-tree code has to change. I'm going to work as hard as I can to keep that the case. Only direct forward declarations of the PassManager class are impacted by this change. llvm-svn: 194324
OpenPOWER on IntegriCloud