maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/tools/opt/NewPMDriver.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

432 lines
17 KiB
C++
Raw Normal View History

[PM] Add (very skeletal) support to opt for running the new pass manager. I cannot emphasize enough that this is a WIP. =] I expect it to change a great deal as things stabilize, but I think its really important to get *some* functionality here so that the infrastructure can be tested more traditionally from the commandline. The current design is looking something like this: ./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))' So rather than custom-parsed flags, there is a single flag with a string argument that is parsed into the pass pipeline structure. This makes it really easy to have nice structural properties that are very explicit. There is one obvious and important shortcut. You can start off the pipeline with a pass, and the minimal context of pass managers will be built around the entire specified pipeline. This makes the common case for tests super easy: ./bin/opt -passes=instcombine,sroa,gvn But this won't introduce any of the complexity of the fully inferred old system -- we only ever do this for the *entire* argument, and we only look at the first pass. If the other passes don't fit in the pass manager selected it is a hard error. The other interesting aspect here is that I'm not relying on any registration facilities. Such facilities may be unavoidable for supporting plugins, but I have alternative ideas for plugins that I'd like to try first. My plan is essentially to build everything without registration until we hit an absolute requirement. Instead of registration of pass names, there will be a library dedicated to parsing pass names and the pass pipeline strings described above. Currently, this is directly embedded into opt for simplicity as it is very early, but I plan to eventually pull this into a library that opt, bugpoint, and even Clang can depend on. It should end up as a good home for things like the existing PassManagerBuilder as well. There are a bunch of FIXMEs in the code for the parts of this that are just stubbed out to make the patch more incremental. A quick list of what's coming up directly after this: - Support for function passes and building the structured nesting. - Support for printing the pass structure, and FileCheck tests of all of this code. - The .def-file based pass name parsing. - IR priting passes and the corresponding tests. Some obvious things that I'm not going to do right now, but am definitely planning on as the pass manager work gets a bit further: - Pull the parsing into library, including the builders. - Thread the rest of the target stuff into the new pass manager. - Wire support for the new pass manager up to llc. - Plugin support. Some things that I'd like to have, but are significantly lower on my priority list. I'll get to these eventually, but they may also be places where others want to contribute: - Adding nice error reporting for broken pass pipeline descriptions. - Typo-correction for pass names. llvm-svn: 198998
2014-01-11 16:16:35 +08:00
//===- NewPMDriver.cpp - Driver for opt with new PM -----------------------===//
//
Update the file headers across all of the LLVM projects in the monorepo 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
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
[PM] Add (very skeletal) support to opt for running the new pass manager. I cannot emphasize enough that this is a WIP. =] I expect it to change a great deal as things stabilize, but I think its really important to get *some* functionality here so that the infrastructure can be tested more traditionally from the commandline. The current design is looking something like this: ./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))' So rather than custom-parsed flags, there is a single flag with a string argument that is parsed into the pass pipeline structure. This makes it really easy to have nice structural properties that are very explicit. There is one obvious and important shortcut. You can start off the pipeline with a pass, and the minimal context of pass managers will be built around the entire specified pipeline. This makes the common case for tests super easy: ./bin/opt -passes=instcombine,sroa,gvn But this won't introduce any of the complexity of the fully inferred old system -- we only ever do this for the *entire* argument, and we only look at the first pass. If the other passes don't fit in the pass manager selected it is a hard error. The other interesting aspect here is that I'm not relying on any registration facilities. Such facilities may be unavoidable for supporting plugins, but I have alternative ideas for plugins that I'd like to try first. My plan is essentially to build everything without registration until we hit an absolute requirement. Instead of registration of pass names, there will be a library dedicated to parsing pass names and the pass pipeline strings described above. Currently, this is directly embedded into opt for simplicity as it is very early, but I plan to eventually pull this into a library that opt, bugpoint, and even Clang can depend on. It should end up as a good home for things like the existing PassManagerBuilder as well. There are a bunch of FIXMEs in the code for the parts of this that are just stubbed out to make the patch more incremental. A quick list of what's coming up directly after this: - Support for function passes and building the structured nesting. - Support for printing the pass structure, and FileCheck tests of all of this code. - The .def-file based pass name parsing. - IR priting passes and the corresponding tests. Some obvious things that I'm not going to do right now, but am definitely planning on as the pass manager work gets a bit further: - Pull the parsing into library, including the builders. - Thread the rest of the target stuff into the new pass manager. - Wire support for the new pass manager up to llc. - Plugin support. Some things that I'd like to have, but are significantly lower on my priority list. I'll get to these eventually, but they may also be places where others want to contribute: - Adding nice error reporting for broken pass pipeline descriptions. - Typo-correction for pass names. llvm-svn: 198998
2014-01-11 16:16:35 +08:00
//
//===----------------------------------------------------------------------===//
/// \file
///
/// This file is just a split of the code that logically belongs in opt.cpp but
/// that includes the new pass manager headers.
///
//===----------------------------------------------------------------------===//
#include "NewPMDriver.h"
[opt] Port the debugify passes to the new pass manager llvm-svn: 325294
2018-02-16 05:14:36 +08:00
#include "PassPrinters.h"
[NewPM] Separate out alias analysis passes in opt Summary: This somewhat matches the --aa-pipeline option, which separates out any AA analyses to make sure they run before other passes. Makes check-llvm failures under new PM go from 2356 -> 2303. AA passes are not handled by PassBuilder::parsePassPipeline() but rather PassBuilder::parseAAPipeline(), which is why this fixes some failures. Reviewers: asbirlea, hans, ychen, leonardchan Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82488
2020-06-24 07:11:59 +08:00
#include "llvm/ADT/SmallVector.h"
[PM] Add (very skeletal) support to opt for running the new pass manager. I cannot emphasize enough that this is a WIP. =] I expect it to change a great deal as things stabilize, but I think its really important to get *some* functionality here so that the infrastructure can be tested more traditionally from the commandline. The current design is looking something like this: ./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))' So rather than custom-parsed flags, there is a single flag with a string argument that is parsed into the pass pipeline structure. This makes it really easy to have nice structural properties that are very explicit. There is one obvious and important shortcut. You can start off the pipeline with a pass, and the minimal context of pass managers will be built around the entire specified pipeline. This makes the common case for tests super easy: ./bin/opt -passes=instcombine,sroa,gvn But this won't introduce any of the complexity of the fully inferred old system -- we only ever do this for the *entire* argument, and we only look at the first pass. If the other passes don't fit in the pass manager selected it is a hard error. The other interesting aspect here is that I'm not relying on any registration facilities. Such facilities may be unavoidable for supporting plugins, but I have alternative ideas for plugins that I'd like to try first. My plan is essentially to build everything without registration until we hit an absolute requirement. Instead of registration of pass names, there will be a library dedicated to parsing pass names and the pass pipeline strings described above. Currently, this is directly embedded into opt for simplicity as it is very early, but I plan to eventually pull this into a library that opt, bugpoint, and even Clang can depend on. It should end up as a good home for things like the existing PassManagerBuilder as well. There are a bunch of FIXMEs in the code for the parts of this that are just stubbed out to make the patch more incremental. A quick list of what's coming up directly after this: - Support for function passes and building the structured nesting. - Support for printing the pass structure, and FileCheck tests of all of this code. - The .def-file based pass name parsing. - IR priting passes and the corresponding tests. Some obvious things that I'm not going to do right now, but am definitely planning on as the pass manager work gets a bit further: - Pull the parsing into library, including the builders. - Thread the rest of the target stuff into the new pass manager. - Wire support for the new pass manager up to llc. - Plugin support. Some things that I'd like to have, but are significantly lower on my priority list. I'll get to these eventually, but they may also be places where others want to contribute: - Adding nice error reporting for broken pass pipeline descriptions. - Typo-correction for pass names. llvm-svn: 198998
2014-01-11 16:16:35 +08:00
#include "llvm/ADT/StringRef.h"
[PM/AA] Teach the new pass manager to use pass-by-lambda for registering 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
2016-02-18 17:45:17 +08:00
#include "llvm/Analysis/AliasAnalysis.h"
[PM] Add a new-PM-style CGSCC pass manager using the newly added 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
2014-04-21 19:12:00 +08:00
#include "llvm/Analysis/CGSCCPassManager.h"
[PM] Wire up support for writing bitcode with new PM. This moves the old pass creation functionality to its own header and updates the callers of that routine. Then it adds a new PM supporting bitcode writer to the header file, and wires that up in the opt tool. A test is added that round-trips code into bitcode and back out using the new pass manager. llvm-svn: 199078
2014-01-13 15:38:24 +08:00
#include "llvm/Bitcode/BitcodeWriterPass.h"
IWYU for llvm-config.h in llvm, additions. 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
2018-04-30 22:59:11 +08:00
#include "llvm/Config/llvm-config.h"
[PM] Port domtree to the new pass manager (at last). 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
2015-01-14 18:19:28 +08:00
#include "llvm/IR/Dominators.h"
[PM] Wire up support for printing assembly output from the opt command. This lets us round-trip IR in the expected manner with the opt tool. llvm-svn: 199075
2014-01-13 13:16:45 +08:00
#include "llvm/IR/IRPrintingPasses.h"
[PM] Add (very skeletal) support to opt for running the new pass manager. I cannot emphasize enough that this is a WIP. =] I expect it to change a great deal as things stabilize, but I think its really important to get *some* functionality here so that the infrastructure can be tested more traditionally from the commandline. The current design is looking something like this: ./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))' So rather than custom-parsed flags, there is a single flag with a string argument that is parsed into the pass pipeline structure. This makes it really easy to have nice structural properties that are very explicit. There is one obvious and important shortcut. You can start off the pipeline with a pass, and the minimal context of pass managers will be built around the entire specified pipeline. This makes the common case for tests super easy: ./bin/opt -passes=instcombine,sroa,gvn But this won't introduce any of the complexity of the fully inferred old system -- we only ever do this for the *entire* argument, and we only look at the first pass. If the other passes don't fit in the pass manager selected it is a hard error. The other interesting aspect here is that I'm not relying on any registration facilities. Such facilities may be unavoidable for supporting plugins, but I have alternative ideas for plugins that I'd like to try first. My plan is essentially to build everything without registration until we hit an absolute requirement. Instead of registration of pass names, there will be a library dedicated to parsing pass names and the pass pipeline strings described above. Currently, this is directly embedded into opt for simplicity as it is very early, but I plan to eventually pull this into a library that opt, bugpoint, and even Clang can depend on. It should end up as a good home for things like the existing PassManagerBuilder as well. There are a bunch of FIXMEs in the code for the parts of this that are just stubbed out to make the patch more incremental. A quick list of what's coming up directly after this: - Support for function passes and building the structured nesting. - Support for printing the pass structure, and FileCheck tests of all of this code. - The .def-file based pass name parsing. - IR priting passes and the corresponding tests. Some obvious things that I'm not going to do right now, but am definitely planning on as the pass manager work gets a bit further: - Pull the parsing into library, including the builders. - Thread the rest of the target stuff into the new pass manager. - Wire support for the new pass manager up to llc. - Plugin support. Some things that I'd like to have, but are significantly lower on my priority list. I'll get to these eventually, but they may also be places where others want to contribute: - Adding nice error reporting for broken pass pipeline descriptions. - Typo-correction for pass names. llvm-svn: 198998
2014-01-11 16:16:35 +08:00
#include "llvm/IR/LLVMContext.h"
#include "llvm/IR/Module.h"
#include "llvm/IR/PassManager.h"
[PM] Wire up the Verifier for the new pass manager and connect it to the various opt verifier commandline options. Mostly mechanical wiring of the verifier to the new pass manager. Exercises one of the more unusual aspects of it -- a pass can be either a module or function pass interchangably. If this is ever problematic, we can make things more constrained, but for things like the verifier where there is an "obvious" applicability at both levels, it seems convenient. This is the next-to-last piece of basic functionality left to make the opt commandline driving of the new pass manager minimally functional for testing and further development. There is still a lot to be done there (notably the factoring into .def files to kill the current boilerplate code) but it is relatively uninteresting. The only interesting bit left for minimal functionality is supporting the registration of analyses. I'm planning on doing that on top of the .def file switch mostly because the boilerplate for the analyses would be significantly worse. llvm-svn: 199646
2014-01-20 19:34:08 +08:00
#include "llvm/IR/Verifier.h"
[PM] Create a separate library for high-level pass management code. 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
2015-03-07 17:02:36 +08:00
#include "llvm/Passes/PassBuilder.h"
Re-land r329273: [Plugins] Add a slim plugin API to work together with the 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
2018-04-05 23:04:13 +08:00
#include "llvm/Passes/PassPlugin.h"
[New PM][PassInstrumentation] IR printing support for New Pass Manager 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
2018-09-25 00:08:15 +08:00
#include "llvm/Passes/StandardInstrumentations.h"
[PM] Add (very skeletal) support to opt for running the new pass manager. I cannot emphasize enough that this is a WIP. =] I expect it to change a great deal as things stabilize, but I think its really important to get *some* functionality here so that the infrastructure can be tested more traditionally from the commandline. The current design is looking something like this: ./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))' So rather than custom-parsed flags, there is a single flag with a string argument that is parsed into the pass pipeline structure. This makes it really easy to have nice structural properties that are very explicit. There is one obvious and important shortcut. You can start off the pipeline with a pass, and the minimal context of pass managers will be built around the entire specified pipeline. This makes the common case for tests super easy: ./bin/opt -passes=instcombine,sroa,gvn But this won't introduce any of the complexity of the fully inferred old system -- we only ever do this for the *entire* argument, and we only look at the first pass. If the other passes don't fit in the pass manager selected it is a hard error. The other interesting aspect here is that I'm not relying on any registration facilities. Such facilities may be unavoidable for supporting plugins, but I have alternative ideas for plugins that I'd like to try first. My plan is essentially to build everything without registration until we hit an absolute requirement. Instead of registration of pass names, there will be a library dedicated to parsing pass names and the pass pipeline strings described above. Currently, this is directly embedded into opt for simplicity as it is very early, but I plan to eventually pull this into a library that opt, bugpoint, and even Clang can depend on. It should end up as a good home for things like the existing PassManagerBuilder as well. There are a bunch of FIXMEs in the code for the parts of this that are just stubbed out to make the patch more incremental. A quick list of what's coming up directly after this: - Support for function passes and building the structured nesting. - Support for printing the pass structure, and FileCheck tests of all of this code. - The .def-file based pass name parsing. - IR priting passes and the corresponding tests. Some obvious things that I'm not going to do right now, but am definitely planning on as the pass manager work gets a bit further: - Pull the parsing into library, including the builders. - Thread the rest of the target stuff into the new pass manager. - Wire support for the new pass manager up to llc. - Plugin support. Some things that I'd like to have, but are significantly lower on my priority list. I'll get to these eventually, but they may also be places where others want to contribute: - Adding nice error reporting for broken pass pipeline descriptions. - Typo-correction for pass names. llvm-svn: 198998
2014-01-11 16:16:35 +08:00
#include "llvm/Support/CommandLine.h"
[PM] Wire up support for printing assembly output from the opt command. This lets us round-trip IR in the expected manner with the opt tool. llvm-svn: 199075
2014-01-13 13:16:45 +08:00
#include "llvm/Support/ErrorHandling.h"
[PM] Add (very skeletal) support to opt for running the new pass manager. I cannot emphasize enough that this is a WIP. =] I expect it to change a great deal as things stabilize, but I think its really important to get *some* functionality here so that the infrastructure can be tested more traditionally from the commandline. The current design is looking something like this: ./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))' So rather than custom-parsed flags, there is a single flag with a string argument that is parsed into the pass pipeline structure. This makes it really easy to have nice structural properties that are very explicit. There is one obvious and important shortcut. You can start off the pipeline with a pass, and the minimal context of pass managers will be built around the entire specified pipeline. This makes the common case for tests super easy: ./bin/opt -passes=instcombine,sroa,gvn But this won't introduce any of the complexity of the fully inferred old system -- we only ever do this for the *entire* argument, and we only look at the first pass. If the other passes don't fit in the pass manager selected it is a hard error. The other interesting aspect here is that I'm not relying on any registration facilities. Such facilities may be unavoidable for supporting plugins, but I have alternative ideas for plugins that I'd like to try first. My plan is essentially to build everything without registration until we hit an absolute requirement. Instead of registration of pass names, there will be a library dedicated to parsing pass names and the pass pipeline strings described above. Currently, this is directly embedded into opt for simplicity as it is very early, but I plan to eventually pull this into a library that opt, bugpoint, and even Clang can depend on. It should end up as a good home for things like the existing PassManagerBuilder as well. There are a bunch of FIXMEs in the code for the parts of this that are just stubbed out to make the patch more incremental. A quick list of what's coming up directly after this: - Support for function passes and building the structured nesting. - Support for printing the pass structure, and FileCheck tests of all of this code. - The .def-file based pass name parsing. - IR priting passes and the corresponding tests. Some obvious things that I'm not going to do right now, but am definitely planning on as the pass manager work gets a bit further: - Pull the parsing into library, including the builders. - Thread the rest of the target stuff into the new pass manager. - Wire support for the new pass manager up to llc. - Plugin support. Some things that I'd like to have, but are significantly lower on my priority list. I'll get to these eventually, but they may also be places where others want to contribute: - Adding nice error reporting for broken pass pipeline descriptions. - Typo-correction for pass names. llvm-svn: 198998
2014-01-11 16:16:35 +08:00
#include "llvm/Support/ToolOutputFile.h"
[PM] Port TTI to the new pass manager, introducing a TargetIRAnalysis to 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
2015-02-01 18:11:22 +08:00
#include "llvm/Target/TargetMachine.h"
[ThinLTO] Migrate ThinLTOBitcodeWriter to the new PM. 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
2017-06-01 09:02:12 +08:00
#include "llvm/Transforms/IPO/ThinLTOBitcodeWriter.h"
[NewPM][ASan] Make ASan tests work under NPM Under NPM, the asan-globals-md analysis is required but cannot be run within the asan function pass due to module analyses not being able to run from a function pass. So this pins all tests using "-asan" to the legacy PM and adds a corresponding RUN line with -passes='require<asan-globals-md>,function(asan)'. Now all tests in Instrumentation/AddressSanitizer pass when -enable-new-pm is by default on. Tests were automatically converted using the following python script and failures were manually fixed up. import sys for i in sys.argv: with open(i, 'r') as f: s = f.read() with open(i, 'w') as f: for l in s.splitlines(): if "RUN:" in l and ' -asan -asan-module ' in l and '\\' not in l: f.write(l.replace(' -asan -asan-module ', ' -asan -asan-module -enable-new-pm=0 ')) f.write('\n') f.write(l.replace(' -asan -asan-module ', " -passes='require<asan-globals-md>,function(asan),module(asan-module)' ")) f.write('\n') elif "RUN:" in l and ' -asan ' in l and '\\' not in l: f.write(l.replace(' -asan ', ' -asan -enable-new-pm=0 ')) f.write('\n') f.write(l.replace(' -asan ', " -passes='require<asan-globals-md>,function(asan)' ")) f.write('\n') else: f.write(l) f.write('\n') See https://bugs.llvm.org/show_bug.cgi?id=46611. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D83921
2020-07-18 08:49:46 +08:00
#include "llvm/Transforms/Instrumentation/AddressSanitizer.h"
[PM] Separate the LoopAnalysisManager from the LoopPassManager and move 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
2017-01-11 17:43:56 +08:00
#include "llvm/Transforms/Scalar/LoopPassManager.h"
[debugify] Move the Debugify pass from tools/opt to lib/Transform/Utils 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
2019-11-07 08:08:01 +08:00
#include "llvm/Transforms/Utils/Debugify.h"
[PM] Add (very skeletal) support to opt for running the new pass manager. I cannot emphasize enough that this is a WIP. =] I expect it to change a great deal as things stabilize, but I think its really important to get *some* functionality here so that the infrastructure can be tested more traditionally from the commandline. The current design is looking something like this: ./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))' So rather than custom-parsed flags, there is a single flag with a string argument that is parsed into the pass pipeline structure. This makes it really easy to have nice structural properties that are very explicit. There is one obvious and important shortcut. You can start off the pipeline with a pass, and the minimal context of pass managers will be built around the entire specified pipeline. This makes the common case for tests super easy: ./bin/opt -passes=instcombine,sroa,gvn But this won't introduce any of the complexity of the fully inferred old system -- we only ever do this for the *entire* argument, and we only look at the first pass. If the other passes don't fit in the pass manager selected it is a hard error. The other interesting aspect here is that I'm not relying on any registration facilities. Such facilities may be unavoidable for supporting plugins, but I have alternative ideas for plugins that I'd like to try first. My plan is essentially to build everything without registration until we hit an absolute requirement. Instead of registration of pass names, there will be a library dedicated to parsing pass names and the pass pipeline strings described above. Currently, this is directly embedded into opt for simplicity as it is very early, but I plan to eventually pull this into a library that opt, bugpoint, and even Clang can depend on. It should end up as a good home for things like the existing PassManagerBuilder as well. There are a bunch of FIXMEs in the code for the parts of this that are just stubbed out to make the patch more incremental. A quick list of what's coming up directly after this: - Support for function passes and building the structured nesting. - Support for printing the pass structure, and FileCheck tests of all of this code. - The .def-file based pass name parsing. - IR priting passes and the corresponding tests. Some obvious things that I'm not going to do right now, but am definitely planning on as the pass manager work gets a bit further: - Pull the parsing into library, including the builders. - Thread the rest of the target stuff into the new pass manager. - Wire support for the new pass manager up to llc. - Plugin support. Some things that I'd like to have, but are significantly lower on my priority list. I'll get to these eventually, but they may also be places where others want to contribute: - Adding nice error reporting for broken pass pipeline descriptions. - Typo-correction for pass names. llvm-svn: 198998
2014-01-11 16:16:35 +08:00
using namespace llvm;
[PM] Add an enum for describing the desired output strategy, and run that through the interface rather than a simple bool. This should allow starting to wire up real output to round-trip IR through opt with the new pass manager. llvm-svn: 199071
2014-01-13 11:08:40 +08:00
using namespace opt_tool;
[PM] Add (very skeletal) support to opt for running the new pass manager. I cannot emphasize enough that this is a WIP. =] I expect it to change a great deal as things stabilize, but I think its really important to get *some* functionality here so that the infrastructure can be tested more traditionally from the commandline. The current design is looking something like this: ./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))' So rather than custom-parsed flags, there is a single flag with a string argument that is parsed into the pass pipeline structure. This makes it really easy to have nice structural properties that are very explicit. There is one obvious and important shortcut. You can start off the pipeline with a pass, and the minimal context of pass managers will be built around the entire specified pipeline. This makes the common case for tests super easy: ./bin/opt -passes=instcombine,sroa,gvn But this won't introduce any of the complexity of the fully inferred old system -- we only ever do this for the *entire* argument, and we only look at the first pass. If the other passes don't fit in the pass manager selected it is a hard error. The other interesting aspect here is that I'm not relying on any registration facilities. Such facilities may be unavoidable for supporting plugins, but I have alternative ideas for plugins that I'd like to try first. My plan is essentially to build everything without registration until we hit an absolute requirement. Instead of registration of pass names, there will be a library dedicated to parsing pass names and the pass pipeline strings described above. Currently, this is directly embedded into opt for simplicity as it is very early, but I plan to eventually pull this into a library that opt, bugpoint, and even Clang can depend on. It should end up as a good home for things like the existing PassManagerBuilder as well. There are a bunch of FIXMEs in the code for the parts of this that are just stubbed out to make the patch more incremental. A quick list of what's coming up directly after this: - Support for function passes and building the structured nesting. - Support for printing the pass structure, and FileCheck tests of all of this code. - The .def-file based pass name parsing. - IR priting passes and the corresponding tests. Some obvious things that I'm not going to do right now, but am definitely planning on as the pass manager work gets a bit further: - Pull the parsing into library, including the builders. - Thread the rest of the target stuff into the new pass manager. - Wire support for the new pass manager up to llc. - Plugin support. Some things that I'd like to have, but are significantly lower on my priority list. I'll get to these eventually, but they may also be places where others want to contribute: - Adding nice error reporting for broken pass pipeline descriptions. - Typo-correction for pass names. llvm-svn: 198998
2014-01-11 16:16:35 +08:00
[PM] Push the debug option for the new pass manager into the opt tool 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
2015-01-14 06:42:38 +08:00
static cl::opt<bool>
DebugPM("debug-pass-manager", cl::Hidden,
cl::desc("Print pass management debugging information"));
Re-land r329273: [Plugins] Add a slim plugin API to work together with the 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
2018-04-05 23:04:13 +08:00
static cl::list<std::string>
PassPlugins("load-pass-plugin",
cl::desc("Load passes from plugin library"));
[PM/AA] Teach the new pass manager to use pass-by-lambda for registering 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
2016-02-18 17:45:17 +08:00
// This flag specifies a textual description of the alias analysis pipeline to
// use when querying for aliasing information. It only works in concert with
// the "passes" flag above.
static cl::opt<std::string>
AAPipeline("aa-pipeline",
cl::desc("A textual description of the alias analysis "
"pipeline for handling managed aliasing queries"),
cl::Hidden);
[PM] Enable registration of out-of-tree passes with PassBuilder 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
2017-07-10 18:57:55 +08:00
/// {{@ These options accept textual pipeline descriptions which will be
/// inserted into default pipelines at the respective extension points
static cl::opt<std::string> PeepholeEPPipeline(
"passes-ep-peephole",
cl::desc("A textual description of the function pass pipeline inserted at "
"the Peephole extension points into default pipelines"),
cl::Hidden);
static cl::opt<std::string> LateLoopOptimizationsEPPipeline(
"passes-ep-late-loop-optimizations",
cl::desc(
"A textual description of the loop pass pipeline inserted at "
"the LateLoopOptimizations extension point into default pipelines"),
cl::Hidden);
static cl::opt<std::string> LoopOptimizerEndEPPipeline(
"passes-ep-loop-optimizer-end",
cl::desc("A textual description of the loop pass pipeline inserted at "
"the LoopOptimizerEnd extension point into default pipelines"),
cl::Hidden);
static cl::opt<std::string> ScalarOptimizerLateEPPipeline(
"passes-ep-scalar-optimizer-late",
cl::desc("A textual description of the function pass pipeline inserted at "
"the ScalarOptimizerLate extension point into default pipelines"),
cl::Hidden);
static cl::opt<std::string> CGSCCOptimizerLateEPPipeline(
"passes-ep-cgscc-optimizer-late",
cl::desc("A textual description of the cgscc pass pipeline inserted at "
"the CGSCCOptimizerLate extension point into default pipelines"),
cl::Hidden);
static cl::opt<std::string> VectorizerStartEPPipeline(
"passes-ep-vectorizer-start",
cl::desc("A textual description of the function pass pipeline inserted at "
"the VectorizerStart extension point into default pipelines"),
cl::Hidden);
NewPM: Add an extension point for the start of the pipeline. 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
2018-01-23 09:25:20 +08:00
static cl::opt<std::string> PipelineStartEPPipeline(
"passes-ep-pipeline-start",
cl::desc("A textual description of the function pass pipeline inserted at "
"the PipelineStart extension point into default pipelines"),
cl::Hidden);
Add an OptimizerLast EP 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
2018-11-12 19:17:07 +08:00
static cl::opt<std::string> OptimizerLastEPPipeline(
"passes-ep-optimizer-last",
cl::desc("A textual description of the function pass pipeline inserted at "
"the OptimizerLast extension point into default pipelines"),
cl::Hidden);
Fix full unrolling with new pass manager. Last we looked at this and couldn't come up with a reason to change it, but with a pragma for full loop unrolling we bypass every other loop unroll and then fail to fully unroll a loop when the pragma is set. Move the OnlyWhenForced out of the check and into the initialization of the full unroll pass in the new pass manager. This doesn't show up with the old pass manager. Add a new option to opt so that we can turn off loop unrolling manually since this is a difference between clang and opt. Tested with check-clang and check-llvm.
2020-05-05 04:48:56 +08:00
// Individual pipeline tuning options.
[NewPM][opt] Share -disable-loop-unrolling between pass managers There's no reason to introduce a new option for the NPM. The various PGO options are shared in this manner. Reviewed By: echristo Differential Revision: https://reviews.llvm.org/D83368
2020-07-08 23:50:22 +08:00
extern cl::opt<bool> DisableLoopUnrolling;
Fix full unrolling with new pass manager. Last we looked at this and couldn't come up with a reason to change it, but with a pragma for full loop unrolling we bypass every other loop unroll and then fail to fully unroll a loop when the pragma is set. Move the OnlyWhenForced out of the check and into the initialization of the full unroll pass in the new pass manager. This doesn't show up with the old pass manager. Add a new option to opt so that we can turn off loop unrolling manually since this is a difference between clang and opt. Tested with check-clang and check-llvm.
2020-05-05 04:48:56 +08:00
[PGO] Make pgo related options in opt more consistent. 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
2019-01-17 07:19:02 +08:00
extern cl::opt<PGOKind> PGOKindFlag;
extern cl::opt<std::string> ProfileFile;
[PGO] Context sensitive PGO (part 3) Part 3 of CSPGO changes (mostly related to PassMananger). Differential Revision: https://reviews.llvm.org/D54175 llvm-svn: 355330
2019-03-05 04:21:27 +08:00
extern cl::opt<CSPGOKind> CSPGOKindFlag;
extern cl::opt<std::string> CSProfileGenFile;
Add a flag to remap manglings when reading profile data information. 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
2018-10-11 07:13:47 +08:00
static cl::opt<std::string>
ProfileRemappingFile("profile-remapping-file",
cl::desc("Path to the profile remapping file."),
cl::Hidden);
Make new PM honor -fdebug-info-for-profiling 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
2017-07-26 23:01:20 +08:00
static cl::opt<bool> DebugInfoForProfiling(
"new-pm-debug-info-for-profiling", cl::init(false), cl::Hidden,
cl::desc("Emit special debug info to enable PGO profile generation."));
[PM] Enable registration of out-of-tree passes with PassBuilder 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
2017-07-10 18:57:55 +08:00
/// @}}
[PM] Another post-commit fix in NewPMDriver 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
2017-07-11 19:17:44 +08:00
template <typename PassManagerT>
[NewPM] teach -passes= to emit meaningful error messages 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
2018-10-17 18:36:23 +08:00
bool tryParsePipelineText(PassBuilder &PB,
const cl::opt<std::string> &PipelineOpt) {
if (PipelineOpt.empty())
[PM] Another post-commit fix in NewPMDriver 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
2017-07-11 19:17:44 +08:00
return false;
// Verify the pipeline is parseable:
PassManagerT PM;
[NewPM] teach -passes= to emit meaningful error messages 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
2018-10-17 18:36:23 +08:00
if (auto Err = PB.parsePassPipeline(PM, PipelineOpt)) {
errs() << "Could not parse -" << PipelineOpt.ArgStr
<< " pipeline: " << toString(std::move(Err))
<< "... I'm going to ignore it.\n";
return false;
}
return true;
[PM] Another post-commit fix in NewPMDriver 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
2017-07-11 19:17:44 +08:00
}
[PM] Enable registration of out-of-tree passes with PassBuilder 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
2017-07-10 18:57:55 +08:00
/// If one of the EPPipeline command line options was given, register callbacks
/// for parsing and inserting the given pipeline
static void registerEPCallbacks(PassBuilder &PB, bool VerifyEachPass,
bool DebugLogging) {
[PM] Another post-commit fix in NewPMDriver 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
2017-07-11 19:17:44 +08:00
if (tryParsePipelineText<FunctionPassManager>(PB, PeepholeEPPipeline))
[NewPM] teach -passes= to emit meaningful error messages 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
2018-10-17 18:36:23 +08:00
PB.registerPeepholeEPCallback(
[&PB, VerifyEachPass, DebugLogging](
FunctionPassManager &PM, PassBuilder::OptimizationLevel Level) {
ExitOnError Err("Unable to parse PeepholeEP pipeline: ");
Err(PB.parsePassPipeline(PM, PeepholeEPPipeline, VerifyEachPass,
DebugLogging));
});
[PM] Another post-commit fix in NewPMDriver 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
2017-07-11 19:17:44 +08:00
if (tryParsePipelineText<LoopPassManager>(PB,
LateLoopOptimizationsEPPipeline))
[PM] Enable registration of out-of-tree passes with PassBuilder 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
2017-07-10 18:57:55 +08:00
PB.registerLateLoopOptimizationsEPCallback(
[PM] Fix r307532: Get rid of a dangling reference. Escaping lambda by-reference capture of local variable caused a dangling reference. llvm-svn: 307534
2017-07-10 20:48:51 +08:00
[&PB, VerifyEachPass, DebugLogging](
LoopPassManager &PM, PassBuilder::OptimizationLevel Level) {
[NewPM] teach -passes= to emit meaningful error messages 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
2018-10-17 18:36:23 +08:00
ExitOnError Err("Unable to parse LateLoopOptimizationsEP pipeline: ");
Err(PB.parsePassPipeline(PM, LateLoopOptimizationsEPPipeline,
VerifyEachPass, DebugLogging));
[PM] Enable registration of out-of-tree passes with PassBuilder 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
2017-07-10 18:57:55 +08:00
});
[PM] Another post-commit fix in NewPMDriver 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
2017-07-11 19:17:44 +08:00
if (tryParsePipelineText<LoopPassManager>(PB, LoopOptimizerEndEPPipeline))
[NewPM] teach -passes= to emit meaningful error messages 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
2018-10-17 18:36:23 +08:00
PB.registerLoopOptimizerEndEPCallback(
[&PB, VerifyEachPass, DebugLogging](
LoopPassManager &PM, PassBuilder::OptimizationLevel Level) {
ExitOnError Err("Unable to parse LoopOptimizerEndEP pipeline: ");
Err(PB.parsePassPipeline(PM, LoopOptimizerEndEPPipeline,
VerifyEachPass, DebugLogging));
});
[PM] Another post-commit fix in NewPMDriver 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
2017-07-11 19:17:44 +08:00
if (tryParsePipelineText<FunctionPassManager>(PB,
ScalarOptimizerLateEPPipeline))
[PM] Enable registration of out-of-tree passes with PassBuilder 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
2017-07-10 18:57:55 +08:00
PB.registerScalarOptimizerLateEPCallback(
[PM] Fix r307532: Get rid of a dangling reference. Escaping lambda by-reference capture of local variable caused a dangling reference. llvm-svn: 307534
2017-07-10 20:48:51 +08:00
[&PB, VerifyEachPass, DebugLogging](
FunctionPassManager &PM, PassBuilder::OptimizationLevel Level) {
[NewPM] teach -passes= to emit meaningful error messages 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
2018-10-17 18:36:23 +08:00
ExitOnError Err("Unable to parse ScalarOptimizerLateEP pipeline: ");
Err(PB.parsePassPipeline(PM, ScalarOptimizerLateEPPipeline,
VerifyEachPass, DebugLogging));
[PM] Enable registration of out-of-tree passes with PassBuilder 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
2017-07-10 18:57:55 +08:00
});
[PM] Another post-commit fix in NewPMDriver 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
2017-07-11 19:17:44 +08:00
if (tryParsePipelineText<CGSCCPassManager>(PB, CGSCCOptimizerLateEPPipeline))
[NewPM] teach -passes= to emit meaningful error messages 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
2018-10-17 18:36:23 +08:00
PB.registerCGSCCOptimizerLateEPCallback(
[&PB, VerifyEachPass, DebugLogging](
CGSCCPassManager &PM, PassBuilder::OptimizationLevel Level) {
ExitOnError Err("Unable to parse CGSCCOptimizerLateEP pipeline: ");
Err(PB.parsePassPipeline(PM, CGSCCOptimizerLateEPPipeline,
VerifyEachPass, DebugLogging));
});
[PM] Another post-commit fix in NewPMDriver 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
2017-07-11 19:17:44 +08:00
if (tryParsePipelineText<FunctionPassManager>(PB, VectorizerStartEPPipeline))
[NewPM] teach -passes= to emit meaningful error messages 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
2018-10-17 18:36:23 +08:00
PB.registerVectorizerStartEPCallback(
[&PB, VerifyEachPass, DebugLogging](
FunctionPassManager &PM, PassBuilder::OptimizationLevel Level) {
ExitOnError Err("Unable to parse VectorizerStartEP pipeline: ");
Err(PB.parsePassPipeline(PM, VectorizerStartEPPipeline,
VerifyEachPass, DebugLogging));
});
NewPM: Add an extension point for the start of the pipeline. 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
2018-01-23 09:25:20 +08:00
if (tryParsePipelineText<ModulePassManager>(PB, PipelineStartEPPipeline))
PB.registerPipelineStartEPCallback(
[&PB, VerifyEachPass, DebugLogging](ModulePassManager &PM) {
[NewPM] teach -passes= to emit meaningful error messages 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
2018-10-17 18:36:23 +08:00
ExitOnError Err("Unable to parse PipelineStartEP pipeline: ");
Err(PB.parsePassPipeline(PM, PipelineStartEPPipeline, VerifyEachPass,
DebugLogging));
NewPM: Add an extension point for the start of the pipeline. 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
2018-01-23 09:25:20 +08:00
});
Add an OptimizerLast EP 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
2018-11-12 19:17:07 +08:00
if (tryParsePipelineText<FunctionPassManager>(PB, OptimizerLastEPPipeline))
PB.registerOptimizerLastEPCallback(
Run Coverage pass before other *San passes under new pass manager, round 2 Summary: This was attempted once before in https://reviews.llvm.org/D79698, but was reverted due to the coverage pass running in the wrong part of the pipeline. This commit puts it in the same place as the other sanitizers. This changes PassBuilder.OptimizerLastEPCallbacks to work on a ModulePassManager instead of a FunctionPassManager. That is because SanitizerCoverage cannot (easily) be split into a module pass and a function pass like some of the other sanitizers since in its current implementation it conditionally inserts module constructors based on whether or not it successfully modified functions. This fixes compiler-rt/test/msan/coverage-levels.cpp under the new pass manager (last check-msan test). Currently sanitizers + LTO don't work together under the new pass manager, so I removed tests that checked that this combination works for sancov. Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D80692
2020-05-28 14:12:36 +08:00
[&PB, VerifyEachPass, DebugLogging](ModulePassManager &PM,
Add an OptimizerLast EP 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
2018-11-12 19:17:07 +08:00
PassBuilder::OptimizationLevel) {
[newpm] Fix r346645: Missing consume of the Error return by the pipeline parser llvm-svn: 346649
2018-11-12 20:27:58 +08:00
ExitOnError Err("Unable to parse OptimizerLastEP pipeline: ");
Err(PB.parsePassPipeline(PM, OptimizerLastEPPipeline, VerifyEachPass,
DebugLogging));
Add an OptimizerLast EP 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
2018-11-12 19:17:07 +08:00
});
[PM] Enable registration of out-of-tree passes with PassBuilder 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
2017-07-10 18:57:55 +08:00
}
Generalize the pass registration mechanism used by Polly to any third-party tool 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
2019-06-08 23:37:47 +08:00
#define HANDLE_EXTENSION(Ext) \
llvm::PassPluginLibraryInfo get##Ext##PluginInfo();
#include "llvm/Support/Extension.def"
[Polly][PM] Register polly passes with the opt tool for the new-pm path 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
2017-08-04 17:28:09 +08:00
[ThinLTO] Migrate ThinLTOBitcodeWriter to the new PM. 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
2017-06-01 09:02:12 +08:00
bool llvm::runPassPipeline(StringRef Arg0, Module &M, TargetMachine *TM,
[Support] Rename tool_output_file to ToolOutputFile, NFC This class isn't similar to anything from the STL, so it shouldn't use the STL naming conventions. llvm-svn: 314050
2017-09-23 09:03:17 +08:00
ToolOutputFile *Out, ToolOutputFile *ThinLTOLinkOut,
ToolOutputFile *OptRemarkFile,
[NewPM] Attempt to run opt passes specified via -foo-pass under NPM Summary: In order to enable mass testing of opt under NPM, specifically passes specified via -foo-pass. This is gated under a new opt flag -enable-new-pm. Currently the pass flag parser looks for legacy PM passes with the name "foo" (for opt arg "-foo") and creates a PassInfo for each one. Here we take the (legacy PM) pass name and try to match it with one defined in (NPM) PassRegistry.def. Ultimately if we want all tests to pass like this, we'll need to port all passes to NPM and register them in PassRegistry.def under the same name as they were reigstered in the legacy PM. Maybe at some point we'll migrate all -foo to --passes=foo, but that would be after the NPM switch. Flipping on the flag causes 2XXX failures under check-llvm. By far most of them are passes either not ported to NPM or don't have the same name in PassRegistry.def as their old name. Reviewers: hans, echristo, asbirlea, leonardchan Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82320
2020-06-20 07:22:00 +08:00
StringRef PassPipeline, ArrayRef<StringRef> Passes,
OutputKind OK, VerifierKind VK,
uselistorder: Pull the bit through PrintModulePass Now the callers of `PrintModulePass()` (etc.) that care about use-list order in assembly pass in the flag. llvm-svn: 234969
2015-04-15 10:38:06 +08:00
bool ShouldPreserveAssemblyUseListOrder,
[PM] Port ModuleSummaryIndex analysis to new pass manager 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
2016-08-12 21:53:02 +08:00
bool ShouldPreserveBitcodeUseListOrder,
[opt] Port the debugify passes to the new pass manager llvm-svn: 325294
2018-02-16 05:14:36 +08:00
bool EmitSummaryIndex, bool EmitModuleHash,
[Coroutines][5/6] Add coroutine passes to pipeline Summary: Depends on https://reviews.llvm.org/D71901. The fifth in a series of patches that ports the LLVM coroutines passes to the new pass manager infrastructure. The first 4 patches allow users to run coroutine passes by invoking, for example `opt -passes=coro-early`. However, most of LLVM's tests for coroutines use an option, `opt -enable-coroutines`, which adds all 4 coroutine passes to the appropriate legacy pass manager extension points. This patch does the same, but using the new pass manager: when coroutine features are enabled and the new pass manager is being used, this adds the new-pass-manager-compliant coroutine passes to the pass builder's pipeline. This allows us to run all coroutine tests using the new pass manager (besides those that use the coroutine retcon ABI used by the Swift compiler, which is not yet supported in the new pass manager). Reviewers: GorNishanov, lewissbaker, chandlerc, junparser, wenlei Subscribers: wenlei, EricWF, Prazek, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71902
2019-12-26 21:00:00 +08:00
bool EnableDebugify, bool Coroutines) {
[PM] Enable registration of out-of-tree passes with PassBuilder 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
2017-07-10 18:57:55 +08:00
bool VerifyEachPass = VK == VK_VerifyEachPass;
Add test coverage for new PM PGOOpt handling. 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
2017-07-26 10:00:43 +08:00
Optional<PGOOptions> P;
switch (PGOKindFlag) {
Fix indentation. NFC.
2020-05-01 18:37:59 +08:00
case InstrGen:
P = PGOOptions(ProfileFile, "", "", PGOOptions::IRInstr);
break;
case InstrUse:
P = PGOOptions(ProfileFile, "", ProfileRemappingFile, PGOOptions::IRUse);
break;
case SampleUse:
P = PGOOptions(ProfileFile, "", ProfileRemappingFile,
PGOOptions::SampleUse);
break;
case NoPGO:
if (DebugInfoForProfiling)
P = PGOOptions("", "", "", PGOOptions::NoAction, PGOOptions::NoCSAction,
true);
else
P = None;
}
if (CSPGOKindFlag != NoCSPGO) {
if (P && (P->Action == PGOOptions::IRInstr ||
P->Action == PGOOptions::SampleUse))
errs() << "CSPGOKind cannot be used with IRInstr or SampleUse";
if (CSPGOKindFlag == CSInstrGen) {
if (CSProfileGenFile.empty())
errs() << "CSInstrGen needs to specify CSProfileGenFile";
if (P) {
P->CSAction = PGOOptions::CSIRInstr;
P->CSProfileGenFile = CSProfileGenFile;
} else
P = PGOOptions("", CSProfileGenFile, ProfileRemappingFile,
PGOOptions::NoAction, PGOOptions::CSIRInstr);
} else /* CSPGOKindFlag == CSInstrUse */ {
if (!P)
errs() << "CSInstrUse needs to be together with InstrUse";
P->CSAction = PGOOptions::CSIRUse;
[PGO] Context sensitive PGO (part 3) Part 3 of CSPGO changes (mostly related to PassMananger). Differential Revision: https://reviews.llvm.org/D54175 llvm-svn: 355330
2019-03-05 04:21:27 +08:00
}
Fix indentation. NFC.
2020-05-01 18:37:59 +08:00
}
[New PM][PassInstrumentation] IR printing support for New Pass Manager 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
2018-09-25 00:08:15 +08:00
PassInstrumentationCallbacks PIC;
[NewPM] Support optnone under new pass manager OptNoneInstrumentation is part of StandardInstrumentations. It skips functions (or loops) that are marked optnone. The feature of skipping optional passes for optnone functions under NPM is gated on a -enable-npm-optnone flag. Currently it is by default false. That is because we still need to mark all required passes to be required. Otherwise optnone functions will start having incorrect semantics. After that is done in following changes, we can remove the flag and always enable this. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D83519
2020-07-22 00:48:22 +08:00
StandardInstrumentations SI(DebugPM);
[New PM][PassInstrumentation] IR printing support for New Pass Manager 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
2018-09-25 00:08:15 +08:00
SI.registerCallbacks(PIC);
[Coroutines][5/6] Add coroutine passes to pipeline Summary: Depends on https://reviews.llvm.org/D71901. The fifth in a series of patches that ports the LLVM coroutines passes to the new pass manager infrastructure. The first 4 patches allow users to run coroutine passes by invoking, for example `opt -passes=coro-early`. However, most of LLVM's tests for coroutines use an option, `opt -enable-coroutines`, which adds all 4 coroutine passes to the appropriate legacy pass manager extension points. This patch does the same, but using the new pass manager: when coroutine features are enabled and the new pass manager is being used, this adds the new-pass-manager-compliant coroutine passes to the pass builder's pipeline. This allows us to run all coroutine tests using the new pass manager (besides those that use the coroutine retcon ABI used by the Swift compiler, which is not yet supported in the new pass manager). Reviewers: GorNishanov, lewissbaker, chandlerc, junparser, wenlei Subscribers: wenlei, EricWF, Prazek, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71902
2019-12-26 21:00:00 +08:00
PipelineTuningOptions PTO;
Fix full unrolling with new pass manager. Last we looked at this and couldn't come up with a reason to change it, but with a pragma for full loop unrolling we bypass every other loop unroll and then fail to fully unroll a loop when the pragma is set. Move the OnlyWhenForced out of the check and into the initialization of the full unroll pass in the new pass manager. This doesn't show up with the old pass manager. Add a new option to opt so that we can turn off loop unrolling manually since this is a difference between clang and opt. Tested with check-clang and check-llvm.
2020-05-05 04:48:56 +08:00
// LoopUnrolling defaults on to true and DisableLoopUnrolling is initialized
// to false above so we shouldn't necessarily need to check whether or not the
// option has been enabled.
PTO.LoopUnrolling = !DisableLoopUnrolling;
[Coroutines][5/6] Add coroutine passes to pipeline Summary: Depends on https://reviews.llvm.org/D71901. The fifth in a series of patches that ports the LLVM coroutines passes to the new pass manager infrastructure. The first 4 patches allow users to run coroutine passes by invoking, for example `opt -passes=coro-early`. However, most of LLVM's tests for coroutines use an option, `opt -enable-coroutines`, which adds all 4 coroutine passes to the appropriate legacy pass manager extension points. This patch does the same, but using the new pass manager: when coroutine features are enabled and the new pass manager is being used, this adds the new-pass-manager-compliant coroutine passes to the pass builder's pipeline. This allows us to run all coroutine tests using the new pass manager (besides those that use the coroutine retcon ABI used by the Swift compiler, which is not yet supported in the new pass manager). Reviewers: GorNishanov, lewissbaker, chandlerc, junparser, wenlei Subscribers: wenlei, EricWF, Prazek, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71902
2019-12-26 21:00:00 +08:00
PTO.Coroutines = Coroutines;
PassBuilder PB(TM, PTO, P, &PIC);
[PM] Enable registration of out-of-tree passes with PassBuilder 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
2017-07-10 18:57:55 +08:00
registerEPCallbacks(PB, VerifyEachPass, DebugPM);
[PM] Refactor the analysis registration and pass pipeline parsing to 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
2015-02-01 15:40:05 +08:00
Re-land r329273: [Plugins] Add a slim plugin API to work together with the 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
2018-04-05 23:04:13 +08:00
// Load requested pass plugins and let them register pass builder callbacks
for (auto &PluginFN : PassPlugins) {
auto PassPlugin = PassPlugin::Load(PluginFN);
if (!PassPlugin) {
errs() << "Failed to load passes from '" << PluginFN
<< "'. Request ignored.\n";
continue;
}
PassPlugin->registerPassBuilderCallbacks(PB);
}
[opt] Port the debugify passes to the new pass manager llvm-svn: 325294
2018-02-16 05:14:36 +08:00
// Register a callback that creates the debugify passes as needed.
PB.registerPipelineParsingCallback(
[](StringRef Name, ModulePassManager &MPM,
ArrayRef<PassBuilder::PipelineElement>) {
if (Name == "debugify") {
MPM.addPass(NewPMDebugifyPass());
return true;
} else if (Name == "check-debugify") {
MPM.addPass(NewPMCheckDebugifyPass());
return true;
}
return false;
});
[NewPM][ASan] Make ASan tests work under NPM Under NPM, the asan-globals-md analysis is required but cannot be run within the asan function pass due to module analyses not being able to run from a function pass. So this pins all tests using "-asan" to the legacy PM and adds a corresponding RUN line with -passes='require<asan-globals-md>,function(asan)'. Now all tests in Instrumentation/AddressSanitizer pass when -enable-new-pm is by default on. Tests were automatically converted using the following python script and failures were manually fixed up. import sys for i in sys.argv: with open(i, 'r') as f: s = f.read() with open(i, 'w') as f: for l in s.splitlines(): if "RUN:" in l and ' -asan -asan-module ' in l and '\\' not in l: f.write(l.replace(' -asan -asan-module ', ' -asan -asan-module -enable-new-pm=0 ')) f.write('\n') f.write(l.replace(' -asan -asan-module ', " -passes='require<asan-globals-md>,function(asan),module(asan-module)' ")) f.write('\n') elif "RUN:" in l and ' -asan ' in l and '\\' not in l: f.write(l.replace(' -asan ', ' -asan -enable-new-pm=0 ')) f.write('\n') f.write(l.replace(' -asan ', " -passes='require<asan-globals-md>,function(asan)' ")) f.write('\n') else: f.write(l) f.write('\n') See https://bugs.llvm.org/show_bug.cgi?id=46611. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D83921
2020-07-18 08:49:46 +08:00
PB.registerPipelineParsingCallback(
[](StringRef Name, ModulePassManager &MPM,
ArrayRef<PassBuilder::PipelineElement>) {
if (Name == "asan-pipeline") {
MPM.addPass(
RequireAnalysisPass<ASanGlobalsMetadataAnalysis, Module>());
MPM.addPass(
createModuleToFunctionPassAdaptor(AddressSanitizerPass()));
MPM.addPass(ModuleAddressSanitizerPass());
return true;
} else if (Name == "asan-function-pipeline") {
MPM.addPass(
RequireAnalysisPass<ASanGlobalsMetadataAnalysis, Module>());
MPM.addPass(
createModuleToFunctionPassAdaptor(AddressSanitizerPass()));
return true;
}
return false;
});
[opt] Port the debugify passes to the new pass manager llvm-svn: 325294
2018-02-16 05:14:36 +08:00
Generalize the pass registration mechanism used by Polly to any third-party tool 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
2019-06-08 23:37:47 +08:00
#define HANDLE_EXTENSION(Ext) \
get##Ext##PluginInfo().RegisterPassBuilderCallbacks(PB);
#include "llvm/Support/Extension.def"
[Polly][PM] Register polly passes with the opt tool for the new-pm path 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
2017-08-04 17:28:09 +08:00
[PM/AA] Teach the new pass manager to use pass-by-lambda for registering 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
2016-02-18 17:45:17 +08:00
// Specially handle the alias analysis manager so that we can register
// a custom pipeline of AA passes with it.
AAManager AA;
[NewPM] Separate out alias analysis passes in opt Summary: This somewhat matches the --aa-pipeline option, which separates out any AA analyses to make sure they run before other passes. Makes check-llvm failures under new PM go from 2356 -> 2303. AA passes are not handled by PassBuilder::parsePassPipeline() but rather PassBuilder::parseAAPipeline(), which is why this fixes some failures. Reviewers: asbirlea, hans, ychen, leonardchan Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82488
2020-06-24 07:11:59 +08:00
if (!AAPipeline.empty()) {
assert(Passes.empty() &&
"--aa-pipeline and -foo-pass should not both be specified");
if (auto Err = PB.parseAAPipeline(AA, AAPipeline)) {
errs() << Arg0 << ": " << toString(std::move(Err)) << "\n";
return false;
}
}
// For compatibility with legacy pass manager.
// Alias analyses are not specially specified when using the legacy PM.
SmallVector<StringRef, 4> NonAAPasses;
for (auto PassName : Passes) {
if (PB.isAAPassName(PassName)) {
if (auto Err = PB.parseAAPipeline(AA, PassName)) {
errs() << Arg0 << ": " << toString(std::move(Err)) << "\n";
return false;
}
} else {
NonAAPasses.push_back(PassName);
}
[PM/AA] Teach the new pass manager to use pass-by-lambda for registering 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
2016-02-18 17:45:17 +08:00
}
PM: Implement a basic loop pass manager 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
2016-02-25 15:23:08 +08:00
LoopAnalysisManager LAM(DebugPM);
[PM] Push the debug option for the new pass manager into the opt tool 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
2015-01-14 06:42:38 +08:00
FunctionAnalysisManager FAM(DebugPM);
CGSCCAnalysisManager CGAM(DebugPM);
ModuleAnalysisManager MAM(DebugPM);
[PM] Wire up the analysis managers in the opt driver. This isn't really necessary until we add analyses to the driver, but I have such an analysis ready and wanted to split this out. This is actually exercised by the existing tests of the new pass manager as the analysis managers are cross-checked and validated by the function and module managers. llvm-svn: 200901
2014-02-06 12:25:13 +08:00
[PM/AA] Teach the new pass manager to use pass-by-lambda for registering 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
2016-02-18 17:45:17 +08:00
// Register the AA manager first so that our version is the one used.
FAM.registerPass([&] { return std::move(AA); });
[PM] Move the analysis registry into the Passes.cpp file and provide 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
2015-01-06 10:21:37 +08:00
// Register all the basic analyses with the managers.
[PM] Create a separate library for high-level pass management code. 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
2015-03-07 17:02:36 +08:00
PB.registerModuleAnalyses(MAM);
PB.registerCGSCCAnalyses(CGAM);
PB.registerFunctionAnalyses(FAM);
PM: Implement a basic loop pass manager 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
2016-02-25 15:23:08 +08:00
PB.registerLoopAnalyses(LAM);
[PM] Refactor cross-registration of AM into an helper. Requested by: Chandler Carruth. llvm-svn: 269582
2016-05-15 07:21:50 +08:00
PB.crossRegisterProxies(LAM, FAM, CGAM, MAM);
[PM] Wire up the analysis managers in the opt driver. This isn't really necessary until we add analyses to the driver, but I have such an analysis ready and wanted to split this out. This is actually exercised by the existing tests of the new pass manager as the analysis managers are cross-checked and validated by the function and module managers. llvm-svn: 200901
2014-02-06 12:25:13 +08:00
[PM] Push the debug option for the new pass manager into the opt tool 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
2015-01-14 06:42:38 +08:00
ModulePassManager MPM(DebugPM);
[PM] Wire up the Verifier for the new pass manager and connect it to the various opt verifier commandline options. Mostly mechanical wiring of the verifier to the new pass manager. Exercises one of the more unusual aspects of it -- a pass can be either a module or function pass interchangably. If this is ever problematic, we can make things more constrained, but for things like the verifier where there is an "obvious" applicability at both levels, it seems convenient. This is the next-to-last piece of basic functionality left to make the opt commandline driving of the new pass manager minimally functional for testing and further development. There is still a lot to be done there (notably the factoring into .def files to kill the current boilerplate code) but it is relatively uninteresting. The only interesting bit left for minimal functionality is supporting the registration of analyses. I'm planning on doing that on top of the .def file switch mostly because the boilerplate for the analyses would be significantly worse. llvm-svn: 199646
2014-01-20 19:34:08 +08:00
if (VK > VK_NoVerifier)
MPM.addPass(VerifierPass());
[opt] Port the debugify passes to the new pass manager llvm-svn: 325294
2018-02-16 05:14:36 +08:00
if (EnableDebugify)
MPM.addPass(NewPMDebugifyPass());
[PM] Wire up the Verifier for the new pass manager and connect it to the various opt verifier commandline options. Mostly mechanical wiring of the verifier to the new pass manager. Exercises one of the more unusual aspects of it -- a pass can be either a module or function pass interchangably. If this is ever problematic, we can make things more constrained, but for things like the verifier where there is an "obvious" applicability at both levels, it seems convenient. This is the next-to-last piece of basic functionality left to make the opt commandline driving of the new pass manager minimally functional for testing and further development. There is still a lot to be done there (notably the factoring into .def files to kill the current boilerplate code) but it is relatively uninteresting. The only interesting bit left for minimal functionality is supporting the registration of analyses. I'm planning on doing that on top of the .def file switch mostly because the boilerplate for the analyses would be significantly worse. llvm-svn: 199646
2014-01-20 19:34:08 +08:00
[NewPM] Attempt to run opt passes specified via -foo-pass under NPM Summary: In order to enable mass testing of opt under NPM, specifically passes specified via -foo-pass. This is gated under a new opt flag -enable-new-pm. Currently the pass flag parser looks for legacy PM passes with the name "foo" (for opt arg "-foo") and creates a PassInfo for each one. Here we take the (legacy PM) pass name and try to match it with one defined in (NPM) PassRegistry.def. Ultimately if we want all tests to pass like this, we'll need to port all passes to NPM and register them in PassRegistry.def under the same name as they were reigstered in the legacy PM. Maybe at some point we'll migrate all -foo to --passes=foo, but that would be after the NPM switch. Flipping on the flag causes 2XXX failures under check-llvm. By far most of them are passes either not ported to NPM or don't have the same name in PassRegistry.def as their old name. Reviewers: hans, echristo, asbirlea, leonardchan Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82320
2020-06-20 07:22:00 +08:00
if (!PassPipeline.empty()) {
[NewPM][opt] Assert PassPipeline and Passes don't both contain passes Reviewers: asbirlea Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82512
2020-06-25 08:07:13 +08:00
assert(Passes.empty() &&
"PassPipeline and Passes should not both contain passes");
[NewPM] Attempt to run opt passes specified via -foo-pass under NPM Summary: In order to enable mass testing of opt under NPM, specifically passes specified via -foo-pass. This is gated under a new opt flag -enable-new-pm. Currently the pass flag parser looks for legacy PM passes with the name "foo" (for opt arg "-foo") and creates a PassInfo for each one. Here we take the (legacy PM) pass name and try to match it with one defined in (NPM) PassRegistry.def. Ultimately if we want all tests to pass like this, we'll need to port all passes to NPM and register them in PassRegistry.def under the same name as they were reigstered in the legacy PM. Maybe at some point we'll migrate all -foo to --passes=foo, but that would be after the NPM switch. Flipping on the flag causes 2XXX failures under check-llvm. By far most of them are passes either not ported to NPM or don't have the same name in PassRegistry.def as their old name. Reviewers: hans, echristo, asbirlea, leonardchan Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82320
2020-06-20 07:22:00 +08:00
if (auto Err =
PB.parsePassPipeline(MPM, PassPipeline, VerifyEachPass, DebugPM)) {
errs() << Arg0 << ": " << toString(std::move(Err)) << "\n";
return false;
}
}
[NewPM] Separate out alias analysis passes in opt Summary: This somewhat matches the --aa-pipeline option, which separates out any AA analyses to make sure they run before other passes. Makes check-llvm failures under new PM go from 2356 -> 2303. AA passes are not handled by PassBuilder::parsePassPipeline() but rather PassBuilder::parseAAPipeline(), which is why this fixes some failures. Reviewers: asbirlea, hans, ychen, leonardchan Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82488
2020-06-24 07:11:59 +08:00
for (auto PassName : NonAAPasses) {
[NewPM][opt] Translate -foo-analysis to require<foo-analysis> Fixes 53 check-llvm tests under NPM. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D83633
2020-07-14 02:10:56 +08:00
std::string ModifiedPassName(PassName.begin(), PassName.end());
if (PB.isAnalysisPassName(PassName))
ModifiedPassName = "require<" + ModifiedPassName + ">";
if (auto Err = PB.parsePassPipeline(MPM, ModifiedPassName, VerifyEachPass,
DebugPM)) {
[NewPM] Attempt to run opt passes specified via -foo-pass under NPM Summary: In order to enable mass testing of opt under NPM, specifically passes specified via -foo-pass. This is gated under a new opt flag -enable-new-pm. Currently the pass flag parser looks for legacy PM passes with the name "foo" (for opt arg "-foo") and creates a PassInfo for each one. Here we take the (legacy PM) pass name and try to match it with one defined in (NPM) PassRegistry.def. Ultimately if we want all tests to pass like this, we'll need to port all passes to NPM and register them in PassRegistry.def under the same name as they were reigstered in the legacy PM. Maybe at some point we'll migrate all -foo to --passes=foo, but that would be after the NPM switch. Flipping on the flag causes 2XXX failures under check-llvm. By far most of them are passes either not ported to NPM or don't have the same name in PassRegistry.def as their old name. Reviewers: hans, echristo, asbirlea, leonardchan Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82320
2020-06-20 07:22:00 +08:00
errs() << Arg0 << ": " << toString(std::move(Err)) << "\n";
return false;
}
[PM] Add (very skeletal) support to opt for running the new pass manager. I cannot emphasize enough that this is a WIP. =] I expect it to change a great deal as things stabilize, but I think its really important to get *some* functionality here so that the infrastructure can be tested more traditionally from the commandline. The current design is looking something like this: ./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))' So rather than custom-parsed flags, there is a single flag with a string argument that is parsed into the pass pipeline structure. This makes it really easy to have nice structural properties that are very explicit. There is one obvious and important shortcut. You can start off the pipeline with a pass, and the minimal context of pass managers will be built around the entire specified pipeline. This makes the common case for tests super easy: ./bin/opt -passes=instcombine,sroa,gvn But this won't introduce any of the complexity of the fully inferred old system -- we only ever do this for the *entire* argument, and we only look at the first pass. If the other passes don't fit in the pass manager selected it is a hard error. The other interesting aspect here is that I'm not relying on any registration facilities. Such facilities may be unavoidable for supporting plugins, but I have alternative ideas for plugins that I'd like to try first. My plan is essentially to build everything without registration until we hit an absolute requirement. Instead of registration of pass names, there will be a library dedicated to parsing pass names and the pass pipeline strings described above. Currently, this is directly embedded into opt for simplicity as it is very early, but I plan to eventually pull this into a library that opt, bugpoint, and even Clang can depend on. It should end up as a good home for things like the existing PassManagerBuilder as well. There are a bunch of FIXMEs in the code for the parts of this that are just stubbed out to make the patch more incremental. A quick list of what's coming up directly after this: - Support for function passes and building the structured nesting. - Support for printing the pass structure, and FileCheck tests of all of this code. - The .def-file based pass name parsing. - IR priting passes and the corresponding tests. Some obvious things that I'm not going to do right now, but am definitely planning on as the pass manager work gets a bit further: - Pull the parsing into library, including the builders. - Thread the rest of the target stuff into the new pass manager. - Wire support for the new pass manager up to llc. - Plugin support. Some things that I'd like to have, but are significantly lower on my priority list. I'll get to these eventually, but they may also be places where others want to contribute: - Adding nice error reporting for broken pass pipeline descriptions. - Typo-correction for pass names. llvm-svn: 198998
2014-01-11 16:16:35 +08:00
}
[PM] Wire up the Verifier for the new pass manager and connect it to the various opt verifier commandline options. Mostly mechanical wiring of the verifier to the new pass manager. Exercises one of the more unusual aspects of it -- a pass can be either a module or function pass interchangably. If this is ever problematic, we can make things more constrained, but for things like the verifier where there is an "obvious" applicability at both levels, it seems convenient. This is the next-to-last piece of basic functionality left to make the opt commandline driving of the new pass manager minimally functional for testing and further development. There is still a lot to be done there (notably the factoring into .def files to kill the current boilerplate code) but it is relatively uninteresting. The only interesting bit left for minimal functionality is supporting the registration of analyses. I'm planning on doing that on top of the .def file switch mostly because the boilerplate for the analyses would be significantly worse. llvm-svn: 199646
2014-01-20 19:34:08 +08:00
if (VK > VK_NoVerifier)
MPM.addPass(VerifierPass());
[opt] Port the debugify passes to the new pass manager llvm-svn: 325294
2018-02-16 05:14:36 +08:00
if (EnableDebugify)
MPM.addPass(NewPMCheckDebugifyPass());
[PM] Wire up the Verifier for the new pass manager and connect it to the various opt verifier commandline options. Mostly mechanical wiring of the verifier to the new pass manager. Exercises one of the more unusual aspects of it -- a pass can be either a module or function pass interchangably. If this is ever problematic, we can make things more constrained, but for things like the verifier where there is an "obvious" applicability at both levels, it seems convenient. This is the next-to-last piece of basic functionality left to make the opt commandline driving of the new pass manager minimally functional for testing and further development. There is still a lot to be done there (notably the factoring into .def files to kill the current boilerplate code) but it is relatively uninteresting. The only interesting bit left for minimal functionality is supporting the registration of analyses. I'm planning on doing that on top of the .def file switch mostly because the boilerplate for the analyses would be significantly worse. llvm-svn: 199646
2014-01-20 19:34:08 +08:00
[PM] Wire up support for printing assembly output from the opt command. This lets us round-trip IR in the expected manner with the opt tool. llvm-svn: 199075
2014-01-13 13:16:45 +08:00
// Add any relevant output pass at the end of the pipeline.
switch (OK) {
case OK_NoOutput:
break; // No output pass needed.
case OK_OutputAssembly:
uselistorder: Pull the bit through PrintModulePass Now the callers of `PrintModulePass()` (etc.) that care about use-list order in assembly pass in the flag. llvm-svn: 234969
2015-04-15 10:38:06 +08:00
MPM.addPass(
PrintModulePass(Out->os(), "", ShouldPreserveAssemblyUseListOrder));
[PM] Wire up support for printing assembly output from the opt command. This lets us round-trip IR in the expected manner with the opt tool. llvm-svn: 199075
2014-01-13 13:16:45 +08:00
break;
case OK_OutputBitcode:
[PM] Port ModuleSummaryIndex analysis to new pass manager 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
2016-08-12 21:53:02 +08:00
MPM.addPass(BitcodeWriterPass(Out->os(), ShouldPreserveBitcodeUseListOrder,
EmitSummaryIndex, EmitModuleHash));
[PM] Wire up support for writing bitcode with new PM. This moves the old pass creation functionality to its own header and updates the callers of that routine. Then it adds a new PM supporting bitcode writer to the header file, and wires that up in the opt tool. A test is added that round-trips code into bitcode and back out using the new pass manager. llvm-svn: 199078
2014-01-13 15:38:24 +08:00
break;
[ThinLTO] Migrate ThinLTOBitcodeWriter to the new PM. 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
2017-06-01 09:02:12 +08:00
case OK_OutputThinLTOBitcode:
MPM.addPass(ThinLTOBitcodeWriterPass(
Out->os(), ThinLTOLinkOut ? &ThinLTOLinkOut->os() : nullptr));
break;
[PM] Wire up support for printing assembly output from the opt command. This lets us round-trip IR in the expected manner with the opt tool. llvm-svn: 199075
2014-01-13 13:16:45 +08:00
}
// Before executing passes, print the final values of the LLVM options.
cl::PrintOptionValues();
[PM] Add (very skeletal) support to opt for running the new pass manager. I cannot emphasize enough that this is a WIP. =] I expect it to change a great deal as things stabilize, but I think its really important to get *some* functionality here so that the infrastructure can be tested more traditionally from the commandline. The current design is looking something like this: ./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))' So rather than custom-parsed flags, there is a single flag with a string argument that is parsed into the pass pipeline structure. This makes it really easy to have nice structural properties that are very explicit. There is one obvious and important shortcut. You can start off the pipeline with a pass, and the minimal context of pass managers will be built around the entire specified pipeline. This makes the common case for tests super easy: ./bin/opt -passes=instcombine,sroa,gvn But this won't introduce any of the complexity of the fully inferred old system -- we only ever do this for the *entire* argument, and we only look at the first pass. If the other passes don't fit in the pass manager selected it is a hard error. The other interesting aspect here is that I'm not relying on any registration facilities. Such facilities may be unavoidable for supporting plugins, but I have alternative ideas for plugins that I'd like to try first. My plan is essentially to build everything without registration until we hit an absolute requirement. Instead of registration of pass names, there will be a library dedicated to parsing pass names and the pass pipeline strings described above. Currently, this is directly embedded into opt for simplicity as it is very early, but I plan to eventually pull this into a library that opt, bugpoint, and even Clang can depend on. It should end up as a good home for things like the existing PassManagerBuilder as well. There are a bunch of FIXMEs in the code for the parts of this that are just stubbed out to make the patch more incremental. A quick list of what's coming up directly after this: - Support for function passes and building the structured nesting. - Support for printing the pass structure, and FileCheck tests of all of this code. - The .def-file based pass name parsing. - IR priting passes and the corresponding tests. Some obvious things that I'm not going to do right now, but am definitely planning on as the pass manager work gets a bit further: - Pull the parsing into library, including the builders. - Thread the rest of the target stuff into the new pass manager. - Wire support for the new pass manager up to llc. - Plugin support. Some things that I'd like to have, but are significantly lower on my priority list. I'll get to these eventually, but they may also be places where others want to contribute: - Adding nice error reporting for broken pass pipeline descriptions. - Typo-correction for pass names. llvm-svn: 198998
2014-01-11 16:16:35 +08:00
// Now that we have all of the passes ready, run them.
[PM] Make the AnalysisManager parameter to run methods a reference. 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
2016-03-11 19:05:24 +08:00
MPM.run(M, MAM);
[PM] Add (very skeletal) support to opt for running the new pass manager. I cannot emphasize enough that this is a WIP. =] I expect it to change a great deal as things stabilize, but I think its really important to get *some* functionality here so that the infrastructure can be tested more traditionally from the commandline. The current design is looking something like this: ./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))' So rather than custom-parsed flags, there is a single flag with a string argument that is parsed into the pass pipeline structure. This makes it really easy to have nice structural properties that are very explicit. There is one obvious and important shortcut. You can start off the pipeline with a pass, and the minimal context of pass managers will be built around the entire specified pipeline. This makes the common case for tests super easy: ./bin/opt -passes=instcombine,sroa,gvn But this won't introduce any of the complexity of the fully inferred old system -- we only ever do this for the *entire* argument, and we only look at the first pass. If the other passes don't fit in the pass manager selected it is a hard error. The other interesting aspect here is that I'm not relying on any registration facilities. Such facilities may be unavoidable for supporting plugins, but I have alternative ideas for plugins that I'd like to try first. My plan is essentially to build everything without registration until we hit an absolute requirement. Instead of registration of pass names, there will be a library dedicated to parsing pass names and the pass pipeline strings described above. Currently, this is directly embedded into opt for simplicity as it is very early, but I plan to eventually pull this into a library that opt, bugpoint, and even Clang can depend on. It should end up as a good home for things like the existing PassManagerBuilder as well. There are a bunch of FIXMEs in the code for the parts of this that are just stubbed out to make the patch more incremental. A quick list of what's coming up directly after this: - Support for function passes and building the structured nesting. - Support for printing the pass structure, and FileCheck tests of all of this code. - The .def-file based pass name parsing. - IR priting passes and the corresponding tests. Some obvious things that I'm not going to do right now, but am definitely planning on as the pass manager work gets a bit further: - Pull the parsing into library, including the builders. - Thread the rest of the target stuff into the new pass manager. - Wire support for the new pass manager up to llc. - Plugin support. Some things that I'd like to have, but are significantly lower on my priority list. I'll get to these eventually, but they may also be places where others want to contribute: - Adding nice error reporting for broken pass pipeline descriptions. - Typo-correction for pass names. llvm-svn: 198998
2014-01-11 16:16:35 +08:00
// Declare success.
[ThinLTO] Migrate ThinLTOBitcodeWriter to the new PM. 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
2017-06-01 09:02:12 +08:00
if (OK != OK_NoOutput) {
[PM] Add (very skeletal) support to opt for running the new pass manager. I cannot emphasize enough that this is a WIP. =] I expect it to change a great deal as things stabilize, but I think its really important to get *some* functionality here so that the infrastructure can be tested more traditionally from the commandline. The current design is looking something like this: ./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))' So rather than custom-parsed flags, there is a single flag with a string argument that is parsed into the pass pipeline structure. This makes it really easy to have nice structural properties that are very explicit. There is one obvious and important shortcut. You can start off the pipeline with a pass, and the minimal context of pass managers will be built around the entire specified pipeline. This makes the common case for tests super easy: ./bin/opt -passes=instcombine,sroa,gvn But this won't introduce any of the complexity of the fully inferred old system -- we only ever do this for the *entire* argument, and we only look at the first pass. If the other passes don't fit in the pass manager selected it is a hard error. The other interesting aspect here is that I'm not relying on any registration facilities. Such facilities may be unavoidable for supporting plugins, but I have alternative ideas for plugins that I'd like to try first. My plan is essentially to build everything without registration until we hit an absolute requirement. Instead of registration of pass names, there will be a library dedicated to parsing pass names and the pass pipeline strings described above. Currently, this is directly embedded into opt for simplicity as it is very early, but I plan to eventually pull this into a library that opt, bugpoint, and even Clang can depend on. It should end up as a good home for things like the existing PassManagerBuilder as well. There are a bunch of FIXMEs in the code for the parts of this that are just stubbed out to make the patch more incremental. A quick list of what's coming up directly after this: - Support for function passes and building the structured nesting. - Support for printing the pass structure, and FileCheck tests of all of this code. - The .def-file based pass name parsing. - IR priting passes and the corresponding tests. Some obvious things that I'm not going to do right now, but am definitely planning on as the pass manager work gets a bit further: - Pull the parsing into library, including the builders. - Thread the rest of the target stuff into the new pass manager. - Wire support for the new pass manager up to llc. - Plugin support. Some things that I'd like to have, but are significantly lower on my priority list. I'll get to these eventually, but they may also be places where others want to contribute: - Adding nice error reporting for broken pass pipeline descriptions. - Typo-correction for pass names. llvm-svn: 198998
2014-01-11 16:16:35 +08:00
Out->keep();
[ThinLTO] Migrate ThinLTOBitcodeWriter to the new PM. 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
2017-06-01 09:02:12 +08:00
if (OK == OK_OutputThinLTOBitcode && ThinLTOLinkOut)
ThinLTOLinkOut->keep();
}
Keep Optimization Remark Yaml in NewPM 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
2017-08-20 09:30:45 +08:00
if (OptRemarkFile)
OptRemarkFile->keep();
[PM] Add (very skeletal) support to opt for running the new pass manager. I cannot emphasize enough that this is a WIP. =] I expect it to change a great deal as things stabilize, but I think its really important to get *some* functionality here so that the infrastructure can be tested more traditionally from the commandline. The current design is looking something like this: ./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))' So rather than custom-parsed flags, there is a single flag with a string argument that is parsed into the pass pipeline structure. This makes it really easy to have nice structural properties that are very explicit. There is one obvious and important shortcut. You can start off the pipeline with a pass, and the minimal context of pass managers will be built around the entire specified pipeline. This makes the common case for tests super easy: ./bin/opt -passes=instcombine,sroa,gvn But this won't introduce any of the complexity of the fully inferred old system -- we only ever do this for the *entire* argument, and we only look at the first pass. If the other passes don't fit in the pass manager selected it is a hard error. The other interesting aspect here is that I'm not relying on any registration facilities. Such facilities may be unavoidable for supporting plugins, but I have alternative ideas for plugins that I'd like to try first. My plan is essentially to build everything without registration until we hit an absolute requirement. Instead of registration of pass names, there will be a library dedicated to parsing pass names and the pass pipeline strings described above. Currently, this is directly embedded into opt for simplicity as it is very early, but I plan to eventually pull this into a library that opt, bugpoint, and even Clang can depend on. It should end up as a good home for things like the existing PassManagerBuilder as well. There are a bunch of FIXMEs in the code for the parts of this that are just stubbed out to make the patch more incremental. A quick list of what's coming up directly after this: - Support for function passes and building the structured nesting. - Support for printing the pass structure, and FileCheck tests of all of this code. - The .def-file based pass name parsing. - IR priting passes and the corresponding tests. Some obvious things that I'm not going to do right now, but am definitely planning on as the pass manager work gets a bit further: - Pull the parsing into library, including the builders. - Thread the rest of the target stuff into the new pass manager. - Wire support for the new pass manager up to llc. - Plugin support. Some things that I'd like to have, but are significantly lower on my priority list. I'll get to these eventually, but they may also be places where others want to contribute: - Adding nice error reporting for broken pass pipeline descriptions. - Typo-correction for pass names. llvm-svn: 198998
2014-01-11 16:16:35 +08:00
return true;
}