summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/LegacyPassManager.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Reland: [Timers] Use the pass argument name for JSON keys in time-passesFrancis Visoiu Mistrih2018-06-131-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using clang --save-stats -mllvm -time-passes, both timers and stats end up in the same json file. We could end up with things like: { "asm-printer.EmittedInsts": 1, "time.pass.Virtual Register Map.wall": 2.9015541076660156e-04, "time.pass.Virtual Register Map.user": 2.0500000000000379e-04, "time.pass.Virtual Register Map.sys": 8.5000000000001741e-05, } This patch makes use of the pass argument name (if available) in the JSON key to end up with things like: { "asm-printer.EmittedInsts": 1, "time.pass.virtregmap.wall": 2.9015541076660156e-04, "time.pass.virtregmap.user": 2.0500000000000379e-04, "time.pass.virtregmap.sys": 8.5000000000001741e-05, } This also helps avoiding to write another JSON printer to handle all the cases that we could have in our pass names. Fixed test instead of adding a new one originally from r334649. Differential Revision: https://reviews.llvm.org/D48109 llvm-svn: 334657
* Revert r334649 "[Timers] Use the pass argument name for JSON keys in ↵Francis Visoiu Mistrih2018-06-131-5/+1
| | | | | | | | | | time-passes" This reverts commit r334649. This breaks a test. llvm-svn: 334651
* [Timers] Use the pass argument name for JSON keys in time-passesFrancis Visoiu Mistrih2018-06-131-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using clang --save-stats -mllvm -time-passes, both timers and stats end up in the same json file. We could end up with things like: { "asm-printer.EmittedInsts": 1, "time.pass.Virtual Register Map.wall": 2.9015541076660156e-04, "time.pass.Virtual Register Map.user": 2.0500000000000379e-04, "time.pass.Virtual Register Map.sys": 8.5000000000001741e-05, } This patch makes use of the pass argument name (if available) in the JSON key to end up with things like: { "asm-printer.EmittedInsts": 1, "time.pass.virtregmap.wall": 2.9015541076660156e-04, "time.pass.virtregmap.user": 2.0500000000000379e-04, "time.pass.virtregmap.sys": 8.5000000000001741e-05, } This also helps avoiding to write another JSON printer to handle all the cases that we could have in our pass names. Differential Revision: https://reviews.llvm.org/D48109 llvm-svn: 334649
* [LegacyPM] Use MapVector for OnTheFlyPassManagers.Florian Hahn2018-05-241-4/+4
| | | | | | | | | | | | | | | | | | | | Currently the iteration order of OnTheFlyManagers is not deterministic between executions, which means some of test/Other/opt-*-pipeline.ll tests fail non-deterministically if an additional on-the-fly manager is added, as in D45330. By using MapVector, we always iterate in the insertion order. As we are not removing elements, there shouldn't be a performance hit, except that we store an additional vector with the keys. Reviewers: efriedma, chandlerc, pcc, jhenderson Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D47317 llvm-svn: 333231
* [NFC] Change cast from r332739 to a static castJessica Paquette2018-05-181-1/+2
| | | | | | | | | The casts in the delta computation for size remarks should have been static casts. This fixes that. Thanks to Dávid Bolvanský for pointing that out. llvm-svn: 332758
* Add remarks describing when a pass changes the IR instruction count of a moduleJessica Paquette2018-05-181-3/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a remark which tells the user when a pass changes the number of IR instructions in a module. It can be enabled by using -Rpass-analysis=size-info. The point of this is to make it easier to collect statistics on how passes modify programs in terms of code size. This is similar in concept to timing reports, but using a remark-based interface makes it easy to diff changes over multiple compilations of the same program. By adding functionality like this, we can see * Which passes impact code size the most * How passes impact code size at different optimization levels * Which pass might have contributed the most to an overall code size regression The patch lives in the legacy pass manager, but since it's simply emitting remarks, it shouldn't be too difficult to adapt the functionality to the new pass manager as well. This can also be adapted to handle MachineInstr counts in code gen passes. https://reviews.llvm.org/D38768 llvm-svn: 332739
* [LegacyPassManager] Make 'print-module-scope' cl::Hidden like the rest of ↵Craig Topper2018-04-011-1/+1
| | | | | | the printing options. llvm-svn: 328947
* IR printing improvement for function passes - introducing -print-module-scopeFedor Sergeev2017-12-011-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When debugging function passes it happens to be rather useful to dump the whole module before the transformation and then use this dump to analyze this single transformation by running it separately on that particular module state. Introducing -print-module-scope debugging option that forces all the function-level IR dumps to become whole-module dumps. This option builds on top of normal dumping controls like -print-before/after -filter-print-funcs The plan is to eventually extend this option to cover other local passes (at least loop passes) but that should go as a separate change. Reviewers: sanjoy, weimingz, silvas, fedor.sergeev Reviewed By: weimingz Subscribers: apilipenko, skatkov, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D40245 llvm-svn: 319561
* Mark all library options as hidden.Zachary Turner2017-12-011-12/+10
| | | | | | | | | | | | | | | | | These command line options are not intended for public use, and often don't even make sense in the context of a particular tool anyway. About 90% of them are already hidden, but when people add new options they forget to hide them, so if you were to make a brand new tool today, link against one of LLVM's libraries, and run tool -help you would get a bunch of junk that doesn't make sense for the tool you're writing. This patch hides these options. The real solution is to not have libraries defining command line options, but that's a much larger effort and not something I'm prepared to take on. Differential Revision: https://reviews.llvm.org/D40674 llvm-svn: 319505
* [PM] Use range-based for loops in LegacyPassManager.cpp (NFC).Florian Hahn2017-07-131-28/+23
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch replaces a bunch of iterator-based for loops with range-based for loops. There are 2 iterator-based loops left in this file in removeNotPreservedAnalysis, but I think those cannot be replaced by range-based for loops as they modify the container they are iterating over. Unless I missed something, this schould be a NFC and I would appreciate if someone could have a quick look to confirm that. Reviewers: chandlerc, pcc, jhenderson Reviewed By: jhenderson Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D35310 llvm-svn: 307902
* [llvm] Remove double semicolonsMandeep Singh Grang2017-06-061-1/+1
| | | | | | | | | | | | Reviewers: craig.topper, arsenm, mehdi_amini Reviewed By: mehdi_amini Subscribers: mehdi_amini, wdng, nhaehnle, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D33924 llvm-svn: 304767
* [LTO] Print time-passes information at conclusion of LTO codegenJames Henderson2017-05-161-0/+13
| | | | | | | | | | | | | | | | | | | The information collected when requested by -time-passes is only printed when llvm_shutdown is called at the moment. This means that when linking against the LTO library dynamically and using the C interface, it is not possible to see the timing information, because llvm_shutdown cannot be called. This change modifies the LTO code generation functions for both regular LTO and thin LTO to explicitly print and reset the timing information. I have tested that this works with our proprietary linker. However, as this relies on a specific method of building and linking against the LTO library, I'm not sure how or if this can be tested in the LLVM testsuite. Reviewed by: mehdi_amini Differential Revision: https://reviews.llvm.org/D32803 llvm-svn: 303152
* Reverted: Track validity of pass resultsSerge Pavlov2017-01-151-15/+3
| | | | | | Commits r291882 and related r291887. llvm-svn: 292062
* Track validity of pass resultsSerge Pavlov2017-01-131-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | Running tests with expensive checks enabled exhibits some problems with verification of pass results. First, the pass verification may require results of analysis that are not available. For instance, verification of loop info requires results of dominator tree analysis. A pass may be marked as conserving loop info but does not need to be dependent on DominatorTreePass. When a pass manager tries to verify that loop info is valid, it needs dominator tree, but corresponding analysis may be already destroyed as no user of it remained. Another case is a pass that is skipped. For instance, entities with linkage available_externally do not need code generation and such passes are skipped for them. In this case result verification must also be skipped. To solve these problems this change introduces a special flag to the Pass structure to mark passes that have valid results. If this flag is reset, verifications dependent on the pass result are skipped. Differential Revision: https://reviews.llvm.org/D27190 llvm-svn: 291882
* Timer: Track name and description.Matthias Braun2016-11-181-3/+5
| | | | | | | | | | | | | The previously used "names" are rather descriptions (they use multiple words and contain spaces), use short programming language identifier like strings for the "names" which should be used when exporting to machine parseable formats. Also removed a unused TimerGroup from Hexxagon. Differential Revision: https://reviews.llvm.org/D25583 llvm-svn: 287369
* Bitcode: Change the materializer interface to return llvm::Error.Peter Collingbourne2016-11-091-2/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D26439 llvm-svn: 286382
* Replace TimeValue by TimePoint in LegacyPassManager. NFC.Pavel Labath2016-10-251-5/+4
| | | | llvm-svn: 285081
* Turn cl::values() (for enum) from a vararg function to using C++ variadic ↵Mehdi Amini2016-10-081-2/+1
| | | | | | | | | | | | | | | template The core of the change is supposed to be NFC, however it also fixes what I believe was an undefined behavior when calling: va_start(ValueArgs, Desc); with Desc being a StringRef. Differential Revision: https://reviews.llvm.org/D25342 llvm-svn: 283671
* Rangify for loops.Yaron Keren2016-10-021-17/+10
| | | | llvm-svn: 283074
* Use StringRef in Pass/PassManager APIs (NFC)Mehdi Amini2016-10-011-8/+4
| | | | llvm-svn: 283004
* Use the range variant of find instead of unpacking begin/endDavid Majnemer2016-08-111-7/+3
| | | | | | | | | If the result of the find is only used to compare against end(), just use is_contained instead. No functionality change is intended. llvm-svn: 278433
* Remove doInitialization() and doFinalization() member declarations without ↵Yaron Keren2016-04-281-16/+0
| | | | | | | | definitions. Visual C++ 2015 flags this in the IDE. llvm-svn: 267919
* Rangify for loops, NFC.Yaron Keren2016-04-281-22/+14
| | | | llvm-svn: 267889
* Annotate dump() methods with LLVM_DUMP_METHOD, addressing Richard Smith ↵Yaron Keren2016-01-291-1/+1
| | | | | | | | r259192 post commit comment. clang part in r259232, this is the LLVM part of the patch. llvm-svn: 259240
* 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
OpenPOWER on IntegriCloud