[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 09:16:35 +01:00
|
|
|
//===- NewPMDriver.cpp - Driver for opt with new PM -----------------------===//
|
|
|
|
|
//
|
2019-01-19 09:50:56 +01: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 09:16:35 +01: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"
|
2018-02-15 22:14:36 +01:00
|
|
|
#include "PassPrinters.h"
|
2020-06-24 01:11:59 +02: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 09:16:35 +01:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
2016-02-18 10:45:17 +01:00
|
|
|
#include "llvm/Analysis/AliasAnalysis.h"
|
2014-04-21 13:12:00 +02:00
|
|
|
#include "llvm/Analysis/CGSCCPassManager.h"
|
2020-09-18 21:27:28 +02:00
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
2014-01-13 08:38:24 +01:00
|
|
|
#include "llvm/Bitcode/BitcodeWriterPass.h"
|
2018-04-30 16:59:11 +02:00
|
|
|
#include "llvm/Config/llvm-config.h"
|
2015-01-14 11:19:28 +01:00
|
|
|
#include "llvm/IR/Dominators.h"
|
2014-01-13 06:16:45 +01: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 09:16:35 +01:00
|
|
|
#include "llvm/IR/LLVMContext.h"
|
|
|
|
|
#include "llvm/IR/Module.h"
|
|
|
|
|
#include "llvm/IR/PassManager.h"
|
2014-01-20 12:34:08 +01:00
|
|
|
#include "llvm/IR/Verifier.h"
|
2015-03-07 10:02:36 +01:00
|
|
|
#include "llvm/Passes/PassBuilder.h"
|
2018-04-05 17:04:13 +02:00
|
|
|
#include "llvm/Passes/PassPlugin.h"
|
2018-09-24 18:08:15 +02:00
|
|
|
#include "llvm/Passes/StandardInstrumentations.h"
|
2014-01-13 06:16:45 +01: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 09:16:35 +01:00
|
|
|
#include "llvm/Support/ToolOutputFile.h"
|
2015-02-01 11:11:22 +01:00
|
|
|
#include "llvm/Target/TargetMachine.h"
|
2017-06-01 03:02:12 +02: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 02:49:46 +02:00
|
|
|
#include "llvm/Transforms/Instrumentation/AddressSanitizer.h"
|
2017-01-11 10:43:56 +01:00
|
|
|
#include "llvm/Transforms/Scalar/LoopPassManager.h"
|
2019-11-07 01:08:01 +01: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 09:16:35 +01:00
|
|
|
|
|
|
|
|
using namespace llvm;
|
2014-01-13 04:08:40 +01: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 09:16:35 +01:00
|
|
|
|
2020-11-02 17:16:43 +01:00
|
|
|
namespace llvm {
|
|
|
|
|
cl::opt<bool> DebugifyEach(
|
|
|
|
|
"debugify-each",
|
|
|
|
|
cl::desc("Start each pass with debugify and end it with check-debugify"));
|
|
|
|
|
|
|
|
|
|
cl::opt<std::string>
|
|
|
|
|
DebugifyExport("debugify-export",
|
|
|
|
|
cl::desc("Export per-pass debugify statistics to this file"),
|
|
|
|
|
cl::value_desc("filename"));
|
|
|
|
|
} // namespace llvm
|
|
|
|
|
|
2015-01-13 23:42:38 +01:00
|
|
|
static cl::opt<bool>
|
|
|
|
|
DebugPM("debug-pass-manager", cl::Hidden,
|
|
|
|
|
cl::desc("Print pass management debugging information"));
|
|
|
|
|
|
2018-04-05 17:04:13 +02:00
|
|
|
static cl::list<std::string>
|
|
|
|
|
PassPlugins("load-pass-plugin",
|
|
|
|
|
cl::desc("Load passes from plugin library"));
|
|
|
|
|
|
2016-02-18 10:45:17 +01: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 12:57:55 +02: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);
|
2018-01-23 02:25:20 +01:00
|
|
|
static cl::opt<std::string> PipelineStartEPPipeline(
|
|
|
|
|
"passes-ep-pipeline-start",
|
2020-10-30 00:10:17 +01:00
|
|
|
cl::desc("A textual description of the module pass pipeline inserted at "
|
2018-01-23 02:25:20 +01:00
|
|
|
"the PipelineStart extension point into default pipelines"),
|
|
|
|
|
cl::Hidden);
|
2018-11-12 12:17:07 +01:00
|
|
|
static cl::opt<std::string> OptimizerLastEPPipeline(
|
|
|
|
|
"passes-ep-optimizer-last",
|
2020-10-30 00:10:17 +01:00
|
|
|
cl::desc("A textual description of the module pass pipeline inserted at "
|
2018-11-12 12:17:07 +01:00
|
|
|
"the OptimizerLast extension point into default pipelines"),
|
|
|
|
|
cl::Hidden);
|
|
|
|
|
|
2020-05-04 22:48:56 +02:00
|
|
|
// Individual pipeline tuning options.
|
2020-07-08 17:50:22 +02:00
|
|
|
extern cl::opt<bool> DisableLoopUnrolling;
|
2020-05-04 22:48:56 +02:00
|
|
|
|
2019-01-17 00:19:02 +01:00
|
|
|
extern cl::opt<PGOKind> PGOKindFlag;
|
|
|
|
|
extern cl::opt<std::string> ProfileFile;
|
2019-03-04 21:21:27 +01:00
|
|
|
extern cl::opt<CSPGOKind> CSPGOKindFlag;
|
|
|
|
|
extern cl::opt<std::string> CSProfileGenFile;
|
2020-08-18 21:34:19 +02:00
|
|
|
extern cl::opt<bool> DisableBasicAA;
|
2019-03-04 21:21:27 +01:00
|
|
|
|
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 01:13:47 +02:00
|
|
|
static cl::opt<std::string>
|
|
|
|
|
ProfileRemappingFile("profile-remapping-file",
|
|
|
|
|
cl::desc("Path to the profile remapping file."),
|
|
|
|
|
cl::Hidden);
|
2017-07-26 17:01:20 +02: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 12:57:55 +02:00
|
|
|
/// @}}
|
|
|
|
|
|
2017-07-11 13:17:44 +02:00
|
|
|
template <typename PassManagerT>
|
2018-10-17 12:36:23 +02:00
|
|
|
bool tryParsePipelineText(PassBuilder &PB,
|
|
|
|
|
const cl::opt<std::string> &PipelineOpt) {
|
|
|
|
|
if (PipelineOpt.empty())
|
2017-07-11 13:17:44 +02:00
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
// Verify the pipeline is parseable:
|
|
|
|
|
PassManagerT PM;
|
2018-10-17 12:36:23 +02: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;
|
2017-07-11 13:17:44 +02: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 12:57:55 +02:00
|
|
|
/// If one of the EPPipeline command line options was given, register callbacks
|
|
|
|
|
/// for parsing and inserting the given pipeline
|
2020-10-29 23:43:31 +01:00
|
|
|
static void registerEPCallbacks(PassBuilder &PB) {
|
2017-07-11 13:17:44 +02:00
|
|
|
if (tryParsePipelineText<FunctionPassManager>(PB, PeepholeEPPipeline))
|
2018-10-17 12:36:23 +02:00
|
|
|
PB.registerPeepholeEPCallback(
|
2020-10-29 23:43:31 +01:00
|
|
|
[&PB](FunctionPassManager &PM, PassBuilder::OptimizationLevel Level) {
|
2018-10-17 12:36:23 +02:00
|
|
|
ExitOnError Err("Unable to parse PeepholeEP pipeline: ");
|
2020-10-29 23:43:31 +01:00
|
|
|
Err(PB.parsePassPipeline(PM, PeepholeEPPipeline));
|
2018-10-17 12:36:23 +02:00
|
|
|
});
|
2017-07-11 13:17:44 +02: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 12:57:55 +02:00
|
|
|
PB.registerLateLoopOptimizationsEPCallback(
|
2020-10-29 23:43:31 +01:00
|
|
|
[&PB](LoopPassManager &PM, PassBuilder::OptimizationLevel Level) {
|
2018-10-17 12:36:23 +02:00
|
|
|
ExitOnError Err("Unable to parse LateLoopOptimizationsEP pipeline: ");
|
2020-10-29 23:43:31 +01:00
|
|
|
Err(PB.parsePassPipeline(PM, 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 12:57:55 +02:00
|
|
|
});
|
2017-07-11 13:17:44 +02:00
|
|
|
if (tryParsePipelineText<LoopPassManager>(PB, LoopOptimizerEndEPPipeline))
|
2018-10-17 12:36:23 +02:00
|
|
|
PB.registerLoopOptimizerEndEPCallback(
|
2020-10-29 23:43:31 +01:00
|
|
|
[&PB](LoopPassManager &PM, PassBuilder::OptimizationLevel Level) {
|
2018-10-17 12:36:23 +02:00
|
|
|
ExitOnError Err("Unable to parse LoopOptimizerEndEP pipeline: ");
|
2020-10-29 23:43:31 +01:00
|
|
|
Err(PB.parsePassPipeline(PM, LoopOptimizerEndEPPipeline));
|
2018-10-17 12:36:23 +02:00
|
|
|
});
|
2017-07-11 13:17:44 +02: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 12:57:55 +02:00
|
|
|
PB.registerScalarOptimizerLateEPCallback(
|
2020-10-29 23:43:31 +01:00
|
|
|
[&PB](FunctionPassManager &PM, PassBuilder::OptimizationLevel Level) {
|
2018-10-17 12:36:23 +02:00
|
|
|
ExitOnError Err("Unable to parse ScalarOptimizerLateEP pipeline: ");
|
2020-10-29 23:43:31 +01:00
|
|
|
Err(PB.parsePassPipeline(PM, 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 12:57:55 +02:00
|
|
|
});
|
2017-07-11 13:17:44 +02:00
|
|
|
if (tryParsePipelineText<CGSCCPassManager>(PB, CGSCCOptimizerLateEPPipeline))
|
2018-10-17 12:36:23 +02:00
|
|
|
PB.registerCGSCCOptimizerLateEPCallback(
|
2020-10-29 23:43:31 +01:00
|
|
|
[&PB](CGSCCPassManager &PM, PassBuilder::OptimizationLevel Level) {
|
2018-10-17 12:36:23 +02:00
|
|
|
ExitOnError Err("Unable to parse CGSCCOptimizerLateEP pipeline: ");
|
2020-10-29 23:43:31 +01:00
|
|
|
Err(PB.parsePassPipeline(PM, CGSCCOptimizerLateEPPipeline));
|
2018-10-17 12:36:23 +02:00
|
|
|
});
|
2017-07-11 13:17:44 +02:00
|
|
|
if (tryParsePipelineText<FunctionPassManager>(PB, VectorizerStartEPPipeline))
|
2018-10-17 12:36:23 +02:00
|
|
|
PB.registerVectorizerStartEPCallback(
|
2020-10-29 23:43:31 +01:00
|
|
|
[&PB](FunctionPassManager &PM, PassBuilder::OptimizationLevel Level) {
|
2018-10-17 12:36:23 +02:00
|
|
|
ExitOnError Err("Unable to parse VectorizerStartEP pipeline: ");
|
2020-10-29 23:43:31 +01:00
|
|
|
Err(PB.parsePassPipeline(PM, VectorizerStartEPPipeline));
|
2018-10-17 12:36:23 +02:00
|
|
|
});
|
2018-01-23 02:25:20 +01:00
|
|
|
if (tryParsePipelineText<ModulePassManager>(PB, PipelineStartEPPipeline))
|
2020-11-04 21:57:32 +01:00
|
|
|
PB.registerPipelineStartEPCallback([&PB](ModulePassManager &PM) {
|
|
|
|
|
ExitOnError Err("Unable to parse PipelineStartEP pipeline: ");
|
|
|
|
|
Err(PB.parsePassPipeline(PM, PipelineStartEPPipeline));
|
|
|
|
|
});
|
2018-11-12 12:17:07 +01:00
|
|
|
if (tryParsePipelineText<FunctionPassManager>(PB, OptimizerLastEPPipeline))
|
|
|
|
|
PB.registerOptimizerLastEPCallback(
|
2020-10-29 23:43:31 +01:00
|
|
|
[&PB](ModulePassManager &PM, PassBuilder::OptimizationLevel) {
|
2018-11-12 13:27:58 +01:00
|
|
|
ExitOnError Err("Unable to parse OptimizerLastEP pipeline: ");
|
2020-10-29 23:43:31 +01:00
|
|
|
Err(PB.parsePassPipeline(PM, OptimizerLastEPPipeline));
|
2018-11-12 12:17:07 +01: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 12:57:55 +02:00
|
|
|
}
|
|
|
|
|
|
2019-06-08 17:37:47 +02:00
|
|
|
#define HANDLE_EXTENSION(Ext) \
|
|
|
|
|
llvm::PassPluginLibraryInfo get##Ext##PluginInfo();
|
|
|
|
|
#include "llvm/Support/Extension.def"
|
2017-08-04 11:28:09 +02:00
|
|
|
|
2017-06-01 03:02:12 +02:00
|
|
|
bool llvm::runPassPipeline(StringRef Arg0, Module &M, TargetMachine *TM,
|
2020-09-18 21:27:28 +02:00
|
|
|
TargetLibraryInfoImpl *TLII, ToolOutputFile *Out,
|
|
|
|
|
ToolOutputFile *ThinLTOLinkOut,
|
2017-09-23 03:03:17 +02:00
|
|
|
ToolOutputFile *OptRemarkFile,
|
2020-06-20 01:22:00 +02:00
|
|
|
StringRef PassPipeline, ArrayRef<StringRef> Passes,
|
|
|
|
|
OutputKind OK, VerifierKind VK,
|
2015-04-15 04:38:06 +02:00
|
|
|
bool ShouldPreserveAssemblyUseListOrder,
|
2016-08-12 15:53:02 +02:00
|
|
|
bool ShouldPreserveBitcodeUseListOrder,
|
2018-02-15 22:14:36 +01: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 14:00:00 +01: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 12:57:55 +02:00
|
|
|
bool VerifyEachPass = VK == VK_VerifyEachPass;
|
2017-07-26 04:00:43 +02:00
|
|
|
|
|
|
|
|
Optional<PGOOptions> P;
|
|
|
|
|
switch (PGOKindFlag) {
|
2020-05-01 12:37:59 +02: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;
|
2019-03-04 21:21:27 +01:00
|
|
|
}
|
2020-05-01 12:37:59 +02:00
|
|
|
}
|
2018-09-24 18:08:15 +02:00
|
|
|
PassInstrumentationCallbacks PIC;
|
2020-09-22 18:34:46 +02:00
|
|
|
StandardInstrumentations SI(DebugPM, VerifyEachPass);
|
2018-09-24 18:08:15 +02:00
|
|
|
SI.registerCallbacks(PIC);
|
2020-11-02 17:16:43 +01:00
|
|
|
DebugifyEachInstrumentation Debugify;
|
|
|
|
|
if (DebugifyEach)
|
|
|
|
|
Debugify.registerCallbacks(PIC);
|
2018-09-24 18:08:15 +02:00
|
|
|
|
[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 14:00:00 +01:00
|
|
|
PipelineTuningOptions PTO;
|
2020-05-04 22:48:56 +02: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 14:00:00 +01:00
|
|
|
PTO.Coroutines = Coroutines;
|
2020-10-29 23:43:31 +01:00
|
|
|
PassBuilder PB(DebugPM, TM, PTO, P, &PIC);
|
|
|
|
|
registerEPCallbacks(PB);
|
2015-02-01 08:40:05 +01:00
|
|
|
|
2018-04-05 17:04:13 +02: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);
|
|
|
|
|
}
|
|
|
|
|
|
2018-02-15 22:14:36 +01: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 02:49:46 +02: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;
|
|
|
|
|
});
|
2018-02-15 22:14:36 +01:00
|
|
|
|
2019-06-08 17:37:47 +02:00
|
|
|
#define HANDLE_EXTENSION(Ext) \
|
|
|
|
|
get##Ext##PluginInfo().RegisterPassBuilderCallbacks(PB);
|
|
|
|
|
#include "llvm/Support/Extension.def"
|
2017-08-04 11:28:09 +02:00
|
|
|
|
2016-02-18 10:45:17 +01:00
|
|
|
// Specially handle the alias analysis manager so that we can register
|
|
|
|
|
// a custom pipeline of AA passes with it.
|
|
|
|
|
AAManager AA;
|
2020-06-24 01:11:59 +02: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.
|
|
|
|
|
for (auto PassName : Passes) {
|
|
|
|
|
if (PB.isAAPassName(PassName)) {
|
|
|
|
|
if (auto Err = PB.parseAAPipeline(AA, PassName)) {
|
|
|
|
|
errs() << Arg0 << ": " << toString(std::move(Err)) << "\n";
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-02-18 10:45:17 +01:00
|
|
|
}
|
2020-08-18 21:34:19 +02:00
|
|
|
// For compatibility with the legacy PM AA pipeline.
|
|
|
|
|
// AAResultsWrapperPass by default provides basic-aa in the legacy PM
|
|
|
|
|
// unless -disable-basic-aa is specified.
|
|
|
|
|
// TODO: remove this once tests implicitly requiring basic-aa use -passes= and
|
|
|
|
|
// -aa-pipeline=basic-aa.
|
|
|
|
|
if (!Passes.empty() && !DisableBasicAA) {
|
|
|
|
|
if (auto Err = PB.parseAAPipeline(AA, "basic-aa")) {
|
|
|
|
|
errs() << Arg0 << ": " << toString(std::move(Err)) << "\n";
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-02-18 10:45:17 +01:00
|
|
|
|
2016-02-25 08:23:08 +01:00
|
|
|
LoopAnalysisManager LAM(DebugPM);
|
2015-01-13 23:42:38 +01:00
|
|
|
FunctionAnalysisManager FAM(DebugPM);
|
|
|
|
|
CGSCCAnalysisManager CGAM(DebugPM);
|
|
|
|
|
ModuleAnalysisManager MAM(DebugPM);
|
2014-02-06 05:25:13 +01:00
|
|
|
|
2016-02-18 10:45:17 +01:00
|
|
|
// Register the AA manager first so that our version is the one used.
|
|
|
|
|
FAM.registerPass([&] { return std::move(AA); });
|
2020-09-18 21:27:28 +02:00
|
|
|
// Register our TargetLibraryInfoImpl.
|
|
|
|
|
FAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
|
2016-02-18 10:45:17 +01:00
|
|
|
|
2015-01-06 03:21:37 +01:00
|
|
|
// Register all the basic analyses with the managers.
|
2015-03-07 10:02:36 +01:00
|
|
|
PB.registerModuleAnalyses(MAM);
|
|
|
|
|
PB.registerCGSCCAnalyses(CGAM);
|
|
|
|
|
PB.registerFunctionAnalyses(FAM);
|
2016-02-25 08:23:08 +01:00
|
|
|
PB.registerLoopAnalyses(LAM);
|
2016-05-15 01:21:50 +02:00
|
|
|
PB.crossRegisterProxies(LAM, FAM, CGAM, MAM);
|
2014-02-06 05:25:13 +01:00
|
|
|
|
2015-01-13 23:42:38 +01:00
|
|
|
ModulePassManager MPM(DebugPM);
|
2014-01-20 12:34:08 +01:00
|
|
|
if (VK > VK_NoVerifier)
|
|
|
|
|
MPM.addPass(VerifierPass());
|
2018-02-15 22:14:36 +01:00
|
|
|
if (EnableDebugify)
|
|
|
|
|
MPM.addPass(NewPMDebugifyPass());
|
2014-01-20 12:34:08 +01:00
|
|
|
|
2020-06-20 01:22:00 +02:00
|
|
|
if (!PassPipeline.empty()) {
|
2020-06-25 02:07:13 +02:00
|
|
|
assert(Passes.empty() &&
|
|
|
|
|
"PassPipeline and Passes should not both contain passes");
|
2020-10-29 23:43:31 +01:00
|
|
|
if (auto Err = PB.parsePassPipeline(MPM, PassPipeline)) {
|
2020-06-20 01:22:00 +02:00
|
|
|
errs() << Arg0 << ": " << toString(std::move(Err)) << "\n";
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-09-16 07:06:50 +02:00
|
|
|
for (auto PassName : Passes) {
|
2020-07-13 20:10:56 +02:00
|
|
|
std::string ModifiedPassName(PassName.begin(), PassName.end());
|
|
|
|
|
if (PB.isAnalysisPassName(PassName))
|
|
|
|
|
ModifiedPassName = "require<" + ModifiedPassName + ">";
|
2020-10-29 23:43:31 +01:00
|
|
|
if (auto Err = PB.parsePassPipeline(MPM, ModifiedPassName)) {
|
2020-06-20 01:22:00 +02: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 09:16:35 +01:00
|
|
|
}
|
|
|
|
|
|
2014-01-20 12:34:08 +01:00
|
|
|
if (VK > VK_NoVerifier)
|
|
|
|
|
MPM.addPass(VerifierPass());
|
2018-02-15 22:14:36 +01:00
|
|
|
if (EnableDebugify)
|
|
|
|
|
MPM.addPass(NewPMCheckDebugifyPass());
|
2014-01-20 12:34:08 +01:00
|
|
|
|
2014-01-13 06:16:45 +01: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:
|
2015-04-15 04:38:06 +02:00
|
|
|
MPM.addPass(
|
|
|
|
|
PrintModulePass(Out->os(), "", ShouldPreserveAssemblyUseListOrder));
|
2014-01-13 06:16:45 +01:00
|
|
|
break;
|
|
|
|
|
case OK_OutputBitcode:
|
2016-08-12 15:53:02 +02:00
|
|
|
MPM.addPass(BitcodeWriterPass(Out->os(), ShouldPreserveBitcodeUseListOrder,
|
|
|
|
|
EmitSummaryIndex, EmitModuleHash));
|
2014-01-13 08:38:24 +01:00
|
|
|
break;
|
2017-06-01 03:02:12 +02:00
|
|
|
case OK_OutputThinLTOBitcode:
|
|
|
|
|
MPM.addPass(ThinLTOBitcodeWriterPass(
|
|
|
|
|
Out->os(), ThinLTOLinkOut ? &ThinLTOLinkOut->os() : nullptr));
|
|
|
|
|
break;
|
2014-01-13 06:16:45 +01: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 09:16:35 +01:00
|
|
|
// Now that we have all of the passes ready, run them.
|
2016-03-11 12:05:24 +01: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 09:16:35 +01:00
|
|
|
|
|
|
|
|
// Declare success.
|
2017-06-01 03:02:12 +02: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 09:16:35 +01:00
|
|
|
Out->keep();
|
2017-06-01 03:02:12 +02:00
|
|
|
if (OK == OK_OutputThinLTOBitcode && ThinLTOLinkOut)
|
|
|
|
|
ThinLTOLinkOut->keep();
|
|
|
|
|
}
|
2017-08-20 03:30:45 +02:00
|
|
|
|
|
|
|
|
if (OptRemarkFile)
|
|
|
|
|
OptRemarkFile->keep();
|
|
|
|
|
|
2020-11-02 17:16:43 +01:00
|
|
|
if (DebugifyEach && !DebugifyExport.empty())
|
|
|
|
|
exportDebugifyStats(DebugifyExport, Debugify.StatsMap);
|
|
|
|
|
|
[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 09:16:35 +01:00
|
|
|
return true;
|
|
|
|
|
}
|
