summaryrefslogtreecommitdiffstats
path: root/llvm/tools/opt/NewPMDriver.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Generalize the pass registration mechanism used by Polly to any third-party toolserge_sans_paille2020-01-021-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | There's quite a lot of references to Polly in the LLVM CMake codebase. However the registration pattern used by Polly could be useful to other external projects: thanks to that mechanism it would be possible to develop LLVM extension without touching the LLVM code base. This patch has two effects: 1. Remove all code specific to Polly in the llvm/clang codebase, replaicing it with a generic mechanism 2. Provide a generic mechanism to register compiler extensions. A compiler extension is similar to a pass plugin, with the notable difference that the compiler extension can be configured to be built dynamically (like plugins) or statically (like regular passes). As a result, people willing to add extra passes to clang/opt can do it using a separate code repo, but still have their pass be linked in clang/opt as built-in passes. Differential Revision: https://reviews.llvm.org/D61446
* [debugify] Move the Debugify pass from tools/opt to lib/Transform/UtilsDaniel Sanders2019-11-071-1/+1
| | | | | | | | | | | | | | | | | | | Summary: I need to make use of this pass from a driver program that isn't opt. Therefore this patch moves this pass into the LLVM library so that it is available for use elsewhere. There was one function I kept in tools/opt which is exportDebugifyStats() this is because it's serializing the statistics into a human readable format and this seemed more in keeping with opt than a library function Reviewers: vsk, aprantl Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69926
* [NewPassManager] Adding pass tuning options: loop vectorize.Alina Sbirlea2019-04-191-1/+1
| | | | | | | | | | | | | | | | Summary: Trying to add the plumbing necessary to add tuning options to the new pass manager. Testing with the flags for loop vectorize. Reviewers: chandlerc Subscribers: sanjoy, mehdi_amini, jlebar, steven_wu, dexonsmith, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59723 llvm-svn: 358763
* [PGO] Context sensitive PGO (part 3)Rong Xu2019-03-041-5/+29
| | | | | | | | Part 3 of CSPGO changes (mostly related to PassMananger). Differential Revision: https://reviews.llvm.org/D54175 llvm-svn: 355330
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [PGO] Make pgo related options in opt more consistent.Wei Mi2019-01-161-13/+2
| | | | | | | | | | | | | | | Currently we have pgo options defined in PassManagerBuilder.cpp only for instrument pgo, but not for sample pgo. We also have pgo options defined in NewPMDriver.cpp in opt only for new pass manager and for all kinds of pgo. They have some inconsistency. To make the options more consistent and make tests writing easier, the patch let old pass manager to share the same pgo options with new pass manager in opt, and removes the options in PassManagerBuilder.cpp. Differential Revision: https://reviews.llvm.org/D56749 llvm-svn: 351392
* [newpm] Fix r346645: Missing consume of the Error return by the pipeline parserPhilip Pfaffe2018-11-121-2/+3
| | | | llvm-svn: 346649
* Add an OptimizerLast EPPhilip Pfaffe2018-11-121-0/+13
| | | | | | | | | | | | | | | | | Summary: It turns out that we need an OptimizerLast PassBuilder extension point after all. I missed the relevance of this EP the first time. By legacy PM magic, function passes added at this EP get added to the last _Function_ PM, which is a feature we lost when dropping this EP for the new PM. A key difference between this and the legacy PassManager's OptimizerLast callback is that this extension point is not triggered at O0. Extensions to the O0 pipeline should append their passes to the end of the overall pipeline. Differential Revision: https://reviews.llvm.org/D54374 llvm-svn: 346645
* [NewPM] teach -passes= to emit meaningful error messagesFedor Sergeev2018-10-171-38/+52
| | | | | | | | | | | | | | All the PassBuilder::parse interfaces now return descriptive StringError instead of a plain bool. It allows to make -passes/aa-pipeline parsing errors context-specific and thus less confusing. TODO: ideally we should also make suggestions for misspelled pass names, but that requires some extensions to PassBuilder. Reviewed By: philip.pfaffe, chandlerc Differential Revision: https://reviews.llvm.org/D53246 llvm-svn: 344685
* Revert "[NewPM] teach -passes= to emit meaningful error messages"Fedor Sergeev2018-10-151-48/+36
| | | | | | This reverts r344519 due to failures in pipeline-parsing test. llvm-svn: 344524
* [NewPM] teach -passes= to emit meaningful error messagesFedor Sergeev2018-10-151-36/+48
| | | | | | | | | | | | | | | Summary: All the PassBuilder::parse interfaces now return descriptive StringError instead of a plain bool. It allows to make -passes/aa-pipeline parsing errors context-specific and thus less confusing. TODO: ideally we should also make suggestions for misspelled pass names, but that requires some extensions to PassBuilder. Reviewed By: philip.pfaffe, chandlerc Differential Revision: https://reviews.llvm.org/D53246 llvm-svn: 344519
* Add a flag to remap manglings when reading profile data information.Richard Smith2018-10-101-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This can be used to preserve profiling information across codebase changes that have widespread impact on mangled names, but across which most profiling data should still be usable. For example, when switching from libstdc++ to libc++, or from the old libstdc++ ABI to the new ABI, or even from a 32-bit to a 64-bit build. The user can provide a remapping file specifying parts of mangled names that should be treated as equivalent (eg, std::__1 should be treated as equivalent to std::__cxx11), and profile data will be treated as applying to a particular function if its name is equivalent to the name of a function in the profile data under the provided equivalences. See the documentation change for a description of how this is configured. Remapping is supported for both sample-based profiling and instruction profiling. We do not support remapping indirect branch target information, but all other profile data should be remapped appropriately. Support is only added for the new pass manager. If someone wants to also add support for this for the old pass manager, doing so should be straightforward. This is the LLVM side of Clang r344199. Reviewers: davidxl, tejohnson, dlj, erik.pilkington Subscribers: mehdi_amini, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D51249 llvm-svn: 344200
* [New PM][PassInstrumentation] IR printing support for New Pass ManagerFedor Sergeev2018-09-241-2/+7
| | | | | | | | | | | | | | | | Implementing -print-before-all/-print-after-all/-filter-print-func support through PassInstrumentation callbacks. - PrintIR routines implement printing callbacks. - StandardInstrumentations class provides a central place to manage all the "standard" in-tree pass instrumentations. Currently it registers PrintIR callbacks. Reviewers: chandlerc, paquette, philip.pfaffe Differential Revision: https://reviews.llvm.org/D50923 llvm-svn: 342896
* [Debugify] Move interface definitions to a header, NFCVedant Kumar2018-07-241-0/+1
| | | | | | | | This is a minor cleanup in preparation for a change to export DI statistics from -check-debugify. To do that, it would be cleaner to have a dedicated header for the debugify interface. llvm-svn: 337786
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* Re-land r329273: [Plugins] Add a slim plugin API to work together with the ↵Philip Pfaffe2018-04-051-0/+17
| | | | | | | | | new PM Fix unittest: Do not link LLVM into the test plugin. Additionally, remove an unrelated change that slipped in in r329273. llvm-svn: 329293
* Revert "[Plugins] Add a slim plugin API to work together with the new PM"Philip Pfaffe2018-04-051-17/+0
| | | | | | This reverts commit ecf3ba1ab45edb1b0fadce716a7facf50dca4fbb/r329273. llvm-svn: 329276
* [Plugins] Add a slim plugin API to work together with the new PMPhilip Pfaffe2018-04-051-0/+17
| | | | | | | | | | | | | | | | | | | | | | Summary: Add a new plugin API. This closes the gap between pass registration and out-of-tree passes for the new PassManager. Unlike with the existing API, interaction with a plugin is always initiated from the tools perspective. I.e., when a plugin is loaded, it resolves and calls a well-known symbol `llvmGetPassPluginInfo` to obtain details about the plugin. The fundamental motivation is to get rid of as many global constructors as possible. The API exposed by the plugin info is kept intentionally minimal. Reviewers: chandlerc Reviewed By: chandlerc Subscribers: bollu, grosser, lksbhm, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D35258 llvm-svn: 329273
* [opt] Port the debugify passes to the new pass managerVedant Kumar2018-02-151-1/+21
| | | | llvm-svn: 325294
* NewPM: Add an extension point for the start of the pipeline.David Blaikie2018-01-231-0/+11
| | | | | | | | | | This applies to most pipelines except the LTO and ThinLTO backend actions - it is for use at the beginning of the overall pipeline. This extension point will be used to add the GCOV pass when enabled in Clang. llvm-svn: 323166
* [Support] Rename tool_output_file to ToolOutputFile, NFCReid Kleckner2017-09-231-3/+2
| | | | | | | This class isn't similar to anything from the STL, so it shouldn't use the STL naming conventions. llvm-svn: 314050
* Keep Optimization Remark Yaml in NewPMSam Elliott2017-08-201-0/+5
| | | | | | | | | | | | | | | | | | | Summary: The New Pass Manager infrastructure was forgetting to keep around the optimization remark yaml file that the compiler might have been producing. This meant setting the option to '-' for stdout worked, but setting it to a filename didn't give file output (presumably it was deleted because compilation didn't explicitly keep it). This change just ensures that the file is kept if compilation succeeds. So far I have updated one of the optimization remark output tests to add a version with the new pass manager. It is my intention for this patch to also include changes to all tests that use `-opt-remark-output=` but I wanted to get the code patch ready for review while I was making all those changes. Fixes https://bugs.llvm.org/show_bug.cgi?id=33951 Reviewers: anemet, chandlerc Reviewed By: anemet, chandlerc Subscribers: javed.absar, chandlerc, fhahn, llvm-commits Differential Revision: https://reviews.llvm.org/D36906 llvm-svn: 311271
* [Polly][PM] Register polly passes with the opt tool for the new-pm pathPhilip Pfaffe2017-08-041-0/+11
| | | | | | | | | | | | | | Summary: When polly is linked into the tools because of the LLVM_POLLY_LINK_INTO_TOOLS option being set, we need to register its passes with the PassBuilder. Because polly is linked in, we can directly call its callback registration method, which registers the appropriate callbacks with the new PM's PassBuilder. This essentially follows exactly the way it worked with the legacy PM. Reviewers: grosser, chandlerc, bollu Reviewed By: grosser Subscribers: pollydev, llvm-commits Differential Revision: https://reviews.llvm.org/D36273 llvm-svn: 310043
* Make new PM honor -fdebug-info-for-profilingDehao Chen2017-07-261-1/+7
| | | | | | | | | | | | | | Summary: The new PM needs to invoke add-discriminator pass when building with -fdebug-info-for-profiling. Reviewers: chandlerc, davidxl Reviewed By: chandlerc Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D35744 llvm-svn: 309121
* Add test coverage for new PM PGOOpt handling.Dehao Chen2017-07-261-1/+29
| | | | | | | | | | | | | | Summary: This patch adds flags and tests to cover the PGOOpt handling logic in new PM. Reviewers: chandlerc, davide Reviewed By: chandlerc Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D35807 llvm-svn: 309076
* [PM] Another post-commit fix in NewPMDriverPhilip Pfaffe2017-07-111-18/+35
| | | | | | | | | | | There were two errors in the parsing of opt's command line options for extension point pipelines. The EP callbacks are not supposed to return a value. To check the pipeline text for correctness, I now try to parse it into a temporary PM object, and print a message on failure. This solves the compile time error for the lambda return type, as well as correctly handles unparsable pipelines now. llvm-svn: 307649
* [PM] Fix a warning.Philip Pfaffe2017-07-101-6/+6
| | | | | | The DebugLogging argument was unused in the EP callbacks registration. llvm-svn: 307536
* [PM] Fix r307532: Get rid of a dangling reference.Philip Pfaffe2017-07-101-22/+24
| | | | | | | Escaping lambda by-reference capture of local variable caused a dangling reference. llvm-svn: 307534
* [PM] Enable registration of out-of-tree passes with PassBuilderPhilip Pfaffe2017-07-101-2/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds a callback registration API to the PassBuilder, enabling registering out-of-tree passes with it. Through the Callback API, callers may register callbacks with the various stages at which passes are added into pass managers, including parsing of a pass pipeline as well as at extension points within the default -O pipelines. Registering utilities like `require<>` and `invalidate<>` needs to be handled manually by the caller, but a helper is provided. Additionally, adding passes at pipeline extension points is exposed through the opt tool. This patch adds a `-passes-ep-X` commandline option for every extension point X, which opt parses into pipelines inserted into that extension point. Reviewers: chandlerc Reviewed By: chandlerc Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D33464 llvm-svn: 307532
* [ThinLTO] Migrate ThinLTOBitcodeWriter to the new PM.Tim Shen2017-06-011-3/+12
| | | | | | | | | | | | Summary: Also see D33429 for other ThinLTO + New PM related changes. Reviewers: davide, chandlerc, tejohnson Subscribers: mehdi_amini, Prazek, cfe-commits, inglorion, llvm-commits, eraman Differential Revision: https://reviews.llvm.org/D33525 llvm-svn: 304378
* [PM] Separate the LoopAnalysisManager from the LoopPassManager and moveChandler Carruth2017-01-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | the latter to the Transforms library. While the loop PM uses an analysis to form the IR units, the current plan is to have the PM itself establish and enforce both loop simplified form and LCSSA. This would be a layering violation in the analysis library. Fundamentally, the idea behind the loop PM is to *transform* loops in addition to running passes over them, so it really seemed like the most natural place to sink this was into the transforms library. We can't just move *everything* because we also have loop analyses that rely on a subset of the invariants. So this patch splits the the loop infrastructure into the analysis management that has to be part of the analysis library, and the transform-aware pass manager. This also required splitting the loop analyses' printer passes out to the transforms library, which makes sense to me as running these will transform the code into LCSSA in theory. I haven't split the unittest though because testing one component without the other seems nearly intractable. Differential Revision: https://reviews.llvm.org/D28452 llvm-svn: 291662
* [opt] Remove an unused argument to runPassPipeline().Davide Italiano2016-09-071-1/+1
| | | | | | I have plans to use this API also in libLTO (and maybe lld). llvm-svn: 280770
* [PM] Port ModuleSummaryIndex analysis to new pass managerTeresa Johnson2016-08-121-3/+4
| | | | | | | | | | | | | | | | | | | Summary: Port the ModuleSummaryAnalysisWrapperPass to the new pass manager. Use it in the ported BitcodeWriterPass (similar to how we use the legacy ModuleSummaryAnalysisWrapperPass in the legacy WriteBitcodePass). Also, pass the -module-summary opt flag through to the new pass manager pipeline and through to the bitcode writer pass, and add a test that uses it. Reviewers: mehdi_amini Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23439 llvm-svn: 278508
* [PM] Refactor cross-registration of AM into an helper.Davide Italiano2016-05-141-10/+1
| | | | | | Requested by: Chandler Carruth. llvm-svn: 269582
* [PM] Make the AnalysisManager parameter to run methods a reference.Chandler Carruth2016-03-111-1/+1
| | | | | | | | | | | | This was originally a pointer to support pass managers which didn't use AnalysisManagers. However, that doesn't realistically come up much and the complexity of supporting it doesn't really make sense. In fact, *many* parts of the pass manager were just assuming the pointer was never null already. This at least makes it much more explicit and clear. llvm-svn: 263219
* PM: Implement a basic loop pass managerJustin Bogner2016-02-251-0/+5
| | | | | | | | | | | This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
* [PM/AA] Teach the new pass manager to use pass-by-lambda for registeringChandler Carruth2016-02-181-6/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | analysis passes, support pre-registering analyses, and use that to implement parsing and pre-registering a custom alias analysis pipeline. With this its possible to configure the particular alias analysis pipeline used by the AAManager from the commandline of opt. I've updated the test to show this effectively in use to build a pipeline including basic-aa as part of it. My big question for reviewers are around the APIs that are used to expose this functionality. Are folks happy with pass-by-lambda to do pass registration? Are folks happy with pre-registering analyses as a way to inject customized instances of an analysis while still using the registry for the general case? Other thoughts of course welcome. The next round of patches will be to add the rest of the alias analyses into the new pass manager and wire them up here so that they can be used from opt. This will require extending the (somewhate limited) functionality of AAManager w.r.t. module passes. Differential Revision: http://reviews.llvm.org/D17259 llvm-svn: 261197
* uselistorder: Pull the bit through PrintModulePassDuncan P. N. Exon Smith2015-04-151-1/+3
| | | | | | | Now the callers of `PrintModulePass()` (etc.) that care about use-list order in assembly pass in the flag. llvm-svn: 234969
* uselistorder: Pull bit through BitcodeWriterPassDuncan P. N. Exon Smith2015-04-151-2/+4
| | | | | | | Now the callers of `BitcodeWriterPass` decide whether or not to preserve bitcode use-list order. llvm-svn: 234959
* [PM] Create a separate library for high-level pass management code.Chandler Carruth2015-03-071-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will provide the analogous replacements for the PassManagerBuilder and other code long term. This code is extracted from the opt tool currently, and I plan to extend it as I build up support for using the new pass manager in Clang and other places. Mailing this out for review in part to let folks comment on the terrible names here. A brief word about why I chose the names I did. The library is called "Passes" to try and make it clear that it is a high-level utility and where *all* of the passes come together and are registered in a common library. I didn't want it to be *limited* to a registry though, the registry is just one component. The class is a "PassBuilder" but this name I'm less happy with. It doesn't build passes in any traditional sense and isn't a Builder-style API at all. The class is a PassRegisterer or PassAdder, but neither of those really make a lot of sense. This class is responsible for constructing passes for registry in an analysis manager or for population of a pass pipeline. If anyone has a better name, I would love to hear it. The other candidate I looked at was PassRegistrar, but that doesn't really fit either. There is no register of all the passes in use, and so I think continuing the "registry" analog outside of the registry of pass *names* and *types* is a mistake. The objects themselves are just objects with the new pass manager. Differential Revision: http://reviews.llvm.org/D8054 llvm-svn: 231556
* [PM] Port TTI to the new pass manager, introducing a TargetIRAnalysis toChandler Carruth2015-02-011-3/+5
| | | | | | | | | | | | | | produce it. This adds a function to the TargetMachine that produces this analysis via a callback for each function. This in turn faves the way to produce a *different* TTI per-function with the correct subtarget cached. I've also done the necessary wiring in the opt tool to thread the target machine down and make it available to the pass registry so that we can construct this analysis from a target machine when available. llvm-svn: 227721
* [PM] Refactor the analysis registration and pass pipeline parsing toChandler Carruth2015-02-011-4/+7
| | | | | | | | | | | live in a class. While this isn't really significant right now, I need to expose some state to the pass construction expressions, and making them get evaluated within a class context is a nice way to collect members that they may need to access. llvm-svn: 227715
* [PM] Port domtree to the new pass manager (at last).Chandler Carruth2015-01-141-0/+1
| | | | | | | | | | | | This adds the domtree analysis to the new pass manager. The analysis returns the same DominatorTree result entity used by the old pass manager and essentially all of the code is shared. We just have different boilerplate for running and printing the analysis. I've converted one test to run in both modes just to make sure this is exercised while both are live in the tree. llvm-svn: 225969
* [PM] Push the debug option for the new pass manager into the opt toolChandler Carruth2015-01-131-5/+9
| | | | | | | | | | and expose the necessary hooks in the API directly. This makes it much cleaner for example to log the usage of a pass manager from a library. It also makes it more obvious that this functionality isn't "optional" or "asserts-only" for the pass manager. llvm-svn: 225841
* [PM] Move the analysis registry into the Passes.cpp file and provideChandler Carruth2015-01-061-12/+4
| | | | | | | | | | | | | | | a normal interface for it in Passes.h. This gives us essentially a single interface for running pass managers which are provided from the bottom of the LLVM stack through interfaces at the top of the LLVM stack that populate them with all of the different analyses available throughout. It also means there is a single blob of code that needs to include all of the pass headers and needs to deal with the registry of passes and parsing names. No functionality changed intended, should just be cleanup. llvm-svn: 225237
* [PM] Switch the new pass manager to use a reference-based API for IRChandler Carruth2015-01-051-1/+1
| | | | | | | | | | | | | | | | | | | | | units. This was debated back and forth a bunch, but using references is now clearly cleaner. Of all the code written using pointers thus far, in only one place did it really make more sense to have a pointer. In most cases, this just removes immediate dereferencing from the code. I think it is much better to get errors on null IR units earlier, potentially at compile time, than to delay it. Most notably, the legacy pass manager uses references for its routines and so as more and more code works with both, the use of pointers was likely to become really annoying. I noticed this when I ported the domtree analysis over and wrote the entire thing with references only to have it fail to compile. =/ It seemed better to switch now than to delay. We can, of course, revisit this is we learn that references are really problematic in the API. llvm-svn: 225145
* [PM] Add a new-PM-style CGSCC pass manager using the newly addedChandler Carruth2014-04-211-0/+10
| | | | | | | | | | | | | | | | | | | | | | | LazyCallGraph analysis framework. Wire it up all the way through the opt driver and add some very basic testing that we can build pass pipelines including these components. Still a lot more to do in terms of testing that all of this works, but the basic pieces are here. There is a *lot* of boiler plate here. It's something I'm going to actively look at reducing, but I don't have any immediate ideas that don't end up making the code terribly complex in order to fold away the boilerplate. Until I figure out something to minimize the boilerplate, almost all of this is based on the code for the existing pass managers, copied and heavily adjusted to suit the needs of the CGSCC pass management layer. The actual CG management still has a bunch of FIXMEs in it. Notably, we don't do *any* updating of the CG as it is potentially invalidated. I wanted to get this in place to motivate the new analysis, and add update APIs to the analysis and the pass management layers in concert to make sure that the *right* APIs are present. llvm-svn: 206745
* [PM] Wire the analysis passes (such as they are) into the registry, andChandler Carruth2014-04-211-3/+7
| | | | | | teach the opt driver to use it rather than a manual list. llvm-svn: 206739
* [PM] Add a new "lazy" call graph analysis pass for the new pass manager.Chandler Carruth2014-02-061-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The primary motivation for this pass is to separate the call graph analysis used by the new pass manager's CGSCC pass management from the existing call graph analysis pass. That analysis pass is (somewhat unfortunately) over-constrained by the existing CallGraphSCCPassManager requirements. Those requirements make it *really* hard to cleanly layer the needed functionality for the new pass manager on top of the existing analysis. However, there are also a bunch of things that the pass manager would specifically benefit from doing differently from the existing call graph analysis, and this new implementation tries to address several of them: - Be lazy about scanning function definitions. The existing pass eagerly scans the entire module to build the initial graph. This new pass is significantly more lazy, and I plan to push this even further to maximize locality during CGSCC walks. - Don't use a single synthetic node to partition functions with an indirect call from functions whose address is taken. This node creates a huge choke-point which would preclude good parallelization across the fanout of the SCC graph when we got to the point of looking at such changes to LLVM. - Use a memory dense and lightweight representation of the call graph rather than value handles and tracking call instructions. This will require explicit update calls instead of some updates working transparently, but should end up being significantly more efficient. The explicit update calls ended up being needed in many cases for the existing call graph so we don't really lose anything. - Doesn't explicitly model SCCs and thus doesn't provide an "identity" for an SCC which is stable across updates. This is essential for the new pass manager to work correctly. - Only form the graph necessary for traversing all of the functions in an SCC friendly order. This is a much simpler graph structure and should be more memory dense. It does limit the ways in which it is appropriate to use this analysis. I wish I had a better name than "call graph". I've commented extensively this aspect. This is still very much a WIP, in fact it is really just the initial bits. But it is about the fourth version of the initial bits that I've implemented with each of the others running into really frustrating problms. This looks like it will actually work and I'd like to split the actual complexity across commits for the sake of my reviewers. =] The rest of the implementation along with lots of wiring will follow somewhat more rapidly now that there is a good path forward. Naturally, this doesn't impact any of the existing optimizer. This code is specific to the new pass manager. A bunch of thanks are deserved for the various folks that have helped with the design of this, especially Nick Lewycky who actually sat with me to go through the fundamentals of the final version here. llvm-svn: 200903
* [PM] Back out one hunk of the patch in r200901 that was *supposed* to goChandler Carruth2014-02-061-4/+0
| | | | | | in my next patch. Sorry for the breakage. llvm-svn: 200902
OpenPOWER on IntegriCloud