2015-03-07 10:02:36 +01:00
|
|
|
//===- Parsing, selection, and construction of pass pipelines --*- C++ -*--===//
|
[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
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
/// \file
|
|
|
|
///
|
2015-03-07 10:02:36 +01:00
|
|
|
/// Interfaces for registering analysis passes, producing common pass manager
|
2015-02-01 08:40:05 +01:00
|
|
|
/// configurations, and parsing of pass pipelines.
|
[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
|
|
|
///
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2015-03-07 10:02:36 +01:00
|
|
|
#ifndef LLVM_PASSES_PASSBUILDER_H
|
|
|
|
#define LLVM_PASSES_PASSBUILDER_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
|
|
|
|
2016-08-03 05:21:41 +02:00
|
|
|
#include "llvm/ADT/Optional.h"
|
2015-01-13 03:51:47 +01:00
|
|
|
#include "llvm/Analysis/CGSCCPassManager.h"
|
2015-01-14 12:23:27 +01:00
|
|
|
#include "llvm/IR/PassManager.h"
|
2018-01-23 02:25:20 +01:00
|
|
|
#include "llvm/Transforms/Instrumentation.h"
|
2017-01-11 10:43:56 +01:00
|
|
|
#include "llvm/Transforms/Scalar/LoopPassManager.h"
|
2016-08-03 05:21:41 +02:00
|
|
|
#include <vector>
|
[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
|
|
|
|
|
|
|
namespace llvm {
|
2016-04-18 11:17:29 +02:00
|
|
|
class StringRef;
|
2016-02-18 10:45:17 +01:00
|
|
|
class AAManager;
|
2015-02-01 11:11:22 +01:00
|
|
|
class TargetMachine;
|
2018-07-19 16:51:32 +02:00
|
|
|
class ModuleSummaryIndex;
|
[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
|
|
|
|
2017-02-13 16:26:22 +01:00
|
|
|
/// A struct capturing PGO tunables.
|
|
|
|
struct PGOOptions {
|
2017-07-26 04:00:43 +02:00
|
|
|
PGOOptions(std::string ProfileGenFile = "", std::string ProfileUseFile = "",
|
2017-07-26 17:01:20 +02:00
|
|
|
std::string SampleProfileFile = "", bool RunProfileGen = false,
|
|
|
|
bool SamplePGOSupport = false)
|
2017-07-26 04:00:43 +02:00
|
|
|
: ProfileGenFile(ProfileGenFile), ProfileUseFile(ProfileUseFile),
|
2017-07-26 17:01:20 +02:00
|
|
|
SampleProfileFile(SampleProfileFile), RunProfileGen(RunProfileGen),
|
2017-07-29 06:10:24 +02:00
|
|
|
SamplePGOSupport(SamplePGOSupport || !SampleProfileFile.empty()) {
|
|
|
|
assert((RunProfileGen ||
|
|
|
|
!SampleProfileFile.empty() ||
|
|
|
|
!ProfileUseFile.empty() ||
|
|
|
|
SamplePGOSupport) && "Illegal PGOOptions.");
|
|
|
|
}
|
2017-07-26 04:00:43 +02:00
|
|
|
std::string ProfileGenFile;
|
|
|
|
std::string ProfileUseFile;
|
|
|
|
std::string SampleProfileFile;
|
|
|
|
bool RunProfileGen;
|
2017-07-26 17:01:20 +02:00
|
|
|
bool SamplePGOSupport;
|
2017-02-13 16:26:22 +01:00
|
|
|
};
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// This class provides access to building LLVM's passes.
|
2015-01-06 03:21:37 +01:00
|
|
|
///
|
2015-02-01 08:40:05 +01:00
|
|
|
/// It's members provide the baseline state available to passes during their
|
|
|
|
/// construction. The \c PassRegistry.def file specifies how to construct all
|
|
|
|
/// of the built-in passes, and those may reference these members during
|
|
|
|
/// construction.
|
2015-03-07 10:02:36 +01:00
|
|
|
class PassBuilder {
|
2015-02-01 11:11:22 +01:00
|
|
|
TargetMachine *TM;
|
2017-02-13 16:26:22 +01:00
|
|
|
Optional<PGOOptions> PGOOpt;
|
2018-09-20 19:08:45 +02:00
|
|
|
PassInstrumentationCallbacks *PIC;
|
2015-02-01 11:11:22 +01:00
|
|
|
|
2015-02-01 08:40:05 +01:00
|
|
|
public:
|
2018-05-01 17:54:18 +02:00
|
|
|
/// A struct to capture parsed pass pipeline names.
|
[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
|
|
|
///
|
|
|
|
/// A pipeline is defined as a series of names, each of which may in itself
|
|
|
|
/// recursively contain a nested pipeline. A name is either the name of a pass
|
|
|
|
/// (e.g. "instcombine") or the name of a pipeline type (e.g. "cgscc"). If the
|
|
|
|
/// name is the name of a pass, the InnerPipeline is empty, since passes
|
|
|
|
/// cannot contain inner pipelines. See parsePassPipeline() for a more
|
|
|
|
/// detailed description of the textual pipeline format.
|
|
|
|
struct PipelineElement {
|
|
|
|
StringRef Name;
|
|
|
|
std::vector<PipelineElement> InnerPipeline;
|
|
|
|
};
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// ThinLTO phase.
|
2017-07-30 06:55:39 +02:00
|
|
|
///
|
|
|
|
/// This enumerates the LLVM ThinLTO optimization phases.
|
|
|
|
enum class ThinLTOPhase {
|
|
|
|
/// No ThinLTO behavior needed.
|
|
|
|
None,
|
|
|
|
// ThinLTO prelink (summary) phase.
|
|
|
|
PreLink,
|
|
|
|
// ThinLTO postlink (backend compile) phase.
|
|
|
|
PostLink
|
|
|
|
};
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// LLVM-provided high-level optimization levels.
|
2016-02-28 23:16:03 +01:00
|
|
|
///
|
|
|
|
/// This enumerates the LLVM-provided high-level optimization levels. Each
|
|
|
|
/// level has a specific goal and rationale.
|
|
|
|
enum OptimizationLevel {
|
|
|
|
/// Disable as many optimizations as possible. This doesn't completely
|
2016-07-16 03:55:45 +02:00
|
|
|
/// disable the optimizer in all cases, for example always_inline functions
|
|
|
|
/// can be required to be inlined for correctness.
|
2016-02-28 23:16:03 +01:00
|
|
|
O0,
|
|
|
|
|
|
|
|
/// Optimize quickly without destroying debuggability.
|
|
|
|
///
|
|
|
|
/// FIXME: The current and historical behavior of this level does *not*
|
|
|
|
/// agree with this goal, but we would like to move toward this goal in the
|
|
|
|
/// future.
|
|
|
|
///
|
|
|
|
/// This level is tuned to produce a result from the optimizer as quickly
|
|
|
|
/// as possible and to avoid destroying debuggability. This tends to result
|
|
|
|
/// in a very good development mode where the compiled code will be
|
|
|
|
/// immediately executed as part of testing. As a consequence, where
|
|
|
|
/// possible, we would like to produce efficient-to-execute code, but not
|
|
|
|
/// if it significantly slows down compilation or would prevent even basic
|
|
|
|
/// debugging of the resulting binary.
|
|
|
|
///
|
|
|
|
/// As an example, complex loop transformations such as versioning,
|
|
|
|
/// vectorization, or fusion might not make sense here due to the degree to
|
|
|
|
/// which the executed code would differ from the source code, and the
|
|
|
|
/// potential compile time cost.
|
|
|
|
O1,
|
|
|
|
|
|
|
|
/// Optimize for fast execution as much as possible without triggering
|
|
|
|
/// significant incremental compile time or code size growth.
|
|
|
|
///
|
|
|
|
/// The key idea is that optimizations at this level should "pay for
|
|
|
|
/// themselves". So if an optimization increases compile time by 5% or
|
|
|
|
/// increases code size by 5% for a particular benchmark, that benchmark
|
|
|
|
/// should also be one which sees a 5% runtime improvement. If the compile
|
|
|
|
/// time or code size penalties happen on average across a diverse range of
|
|
|
|
/// LLVM users' benchmarks, then the improvements should as well.
|
|
|
|
///
|
|
|
|
/// And no matter what, the compile time needs to not grow superlinearly
|
|
|
|
/// with the size of input to LLVM so that users can control the runtime of
|
|
|
|
/// the optimizer in this mode.
|
|
|
|
///
|
|
|
|
/// This is expected to be a good default optimization level for the vast
|
|
|
|
/// majority of users.
|
|
|
|
O2,
|
|
|
|
|
|
|
|
/// Optimize for fast execution as much as possible.
|
|
|
|
///
|
|
|
|
/// This mode is significantly more aggressive in trading off compile time
|
|
|
|
/// and code size to get execution time improvements. The core idea is that
|
|
|
|
/// this mode should include any optimization that helps execution time on
|
|
|
|
/// balance across a diverse collection of benchmarks, even if it increases
|
|
|
|
/// code size or compile time for some benchmarks without corresponding
|
|
|
|
/// improvements to execution time.
|
|
|
|
///
|
|
|
|
/// Despite being willing to trade more compile time off to get improved
|
|
|
|
/// execution time, this mode still tries to avoid superlinear growth in
|
|
|
|
/// order to make even significantly slower compile times at least scale
|
|
|
|
/// reasonably. This does not preclude very substantial constant factor
|
|
|
|
/// costs though.
|
|
|
|
O3,
|
|
|
|
|
|
|
|
/// Similar to \c O2 but tries to optimize for small code size instead of
|
|
|
|
/// fast execution without triggering significant incremental execution
|
|
|
|
/// time slowdowns.
|
|
|
|
///
|
|
|
|
/// The logic here is exactly the same as \c O2, but with code size and
|
|
|
|
/// execution time metrics swapped.
|
|
|
|
///
|
|
|
|
/// A consequence of the different core goal is that this should in general
|
|
|
|
/// produce substantially smaller executables that still run in
|
|
|
|
/// a reasonable amount of time.
|
|
|
|
Os,
|
|
|
|
|
|
|
|
/// A very specialized mode that will optimize for code size at any and all
|
|
|
|
/// costs.
|
|
|
|
///
|
|
|
|
/// This is useful primarily when there are absolute size limitations and
|
|
|
|
/// any effort taken to reduce the size is worth it regardless of the
|
|
|
|
/// execution time impact. You should expect this level to produce rather
|
|
|
|
/// slow, but very small, code.
|
|
|
|
Oz
|
|
|
|
};
|
|
|
|
|
2017-02-13 16:26:22 +01:00
|
|
|
explicit PassBuilder(TargetMachine *TM = nullptr,
|
2018-09-20 19:08:45 +02:00
|
|
|
Optional<PGOOptions> PGOOpt = None,
|
|
|
|
PassInstrumentationCallbacks *PIC = nullptr)
|
|
|
|
: TM(TM), PGOOpt(PGOOpt), PIC(PIC) {}
|
2015-02-01 11:11:22 +01:00
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Cross register the analysis managers through their proxies.
|
2016-05-15 01:21:50 +02:00
|
|
|
///
|
|
|
|
/// This is an interface that can be used to cross register each
|
|
|
|
// AnalysisManager with all the others analysis managers.
|
|
|
|
void crossRegisterProxies(LoopAnalysisManager &LAM,
|
|
|
|
FunctionAnalysisManager &FAM,
|
|
|
|
CGSCCAnalysisManager &CGAM,
|
|
|
|
ModuleAnalysisManager &MAM);
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Registers all available module analysis passes.
|
2015-02-01 08:40:05 +01:00
|
|
|
///
|
|
|
|
/// This is an interface that can be used to populate a \c
|
|
|
|
/// ModuleAnalysisManager with all registered module analyses. Callers can
|
2016-02-18 10:45:17 +01:00
|
|
|
/// still manually register any additional analyses. Callers can also
|
|
|
|
/// pre-register analyses and this will not override those.
|
2015-02-01 08:40:05 +01:00
|
|
|
void registerModuleAnalyses(ModuleAnalysisManager &MAM);
|
2015-01-06 03:21:37 +01:00
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Registers all available CGSCC analysis passes.
|
2015-02-01 08:40:05 +01:00
|
|
|
///
|
|
|
|
/// This is an interface that can be used to populate a \c CGSCCAnalysisManager
|
|
|
|
/// with all registered CGSCC analyses. Callers can still manually register any
|
2016-02-18 10:45:17 +01:00
|
|
|
/// additional analyses. Callers can also pre-register analyses and this will
|
|
|
|
/// not override those.
|
2015-02-01 08:40:05 +01:00
|
|
|
void registerCGSCCAnalyses(CGSCCAnalysisManager &CGAM);
|
2015-01-06 03:21:37 +01:00
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Registers all available function analysis passes.
|
2015-02-01 08:40:05 +01:00
|
|
|
///
|
|
|
|
/// This is an interface that can be used to populate a \c
|
|
|
|
/// FunctionAnalysisManager with all registered function analyses. Callers can
|
2016-02-18 10:45:17 +01:00
|
|
|
/// still manually register any additional analyses. Callers can also
|
|
|
|
/// pre-register analyses and this will not override those.
|
2015-02-01 08:40:05 +01:00
|
|
|
void registerFunctionAnalyses(FunctionAnalysisManager &FAM);
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Registers all available loop analysis passes.
|
2016-02-25 08:23:08 +01:00
|
|
|
///
|
|
|
|
/// This is an interface that can be used to populate a \c LoopAnalysisManager
|
|
|
|
/// with all registered loop analyses. Callers can still manually register any
|
|
|
|
/// additional analyses.
|
|
|
|
void registerLoopAnalyses(LoopAnalysisManager &LAM);
|
|
|
|
|
2016-12-22 07:59:15 +01:00
|
|
|
/// Construct the core LLVM function canonicalization and simplification
|
|
|
|
/// pipeline.
|
|
|
|
///
|
|
|
|
/// This is a long pipeline and uses most of the per-function optimization
|
|
|
|
/// passes in LLVM to canonicalize and simplify the IR. It is suitable to run
|
|
|
|
/// repeatedly over the IR and is not expected to destroy important
|
|
|
|
/// information about the semantics of the IR.
|
|
|
|
///
|
|
|
|
/// Note that \p Level cannot be `O0` here. The pipelines produced are
|
|
|
|
/// only intended for use when attempting to optimize code. If frontends
|
|
|
|
/// require some transformations for semantic reasons, they should explicitly
|
|
|
|
/// build them.
|
2017-07-07 22:53:10 +02:00
|
|
|
///
|
2017-07-30 06:55:39 +02:00
|
|
|
/// \p Phase indicates the current ThinLTO phase.
|
2016-12-22 07:59:15 +01:00
|
|
|
FunctionPassManager
|
|
|
|
buildFunctionSimplificationPipeline(OptimizationLevel Level,
|
2017-07-30 06:55:39 +02:00
|
|
|
ThinLTOPhase Phase,
|
|
|
|
bool DebugLogging = false);
|
2016-12-22 07:59:15 +01:00
|
|
|
|
2017-06-01 13:39:39 +02:00
|
|
|
/// Construct the core LLVM module canonicalization and simplification
|
|
|
|
/// pipeline.
|
|
|
|
///
|
|
|
|
/// This pipeline focuses on canonicalizing and simplifying the entire module
|
|
|
|
/// of IR. Much like the function simplification pipeline above, it is
|
|
|
|
/// suitable to run repeatedly over the IR and is not expected to destroy
|
|
|
|
/// important information. It does, however, perform inlining and other
|
|
|
|
/// heuristic based simplifications that are not strictly reversible.
|
|
|
|
///
|
|
|
|
/// Note that \p Level cannot be `O0` here. The pipelines produced are
|
|
|
|
/// only intended for use when attempting to optimize code. If frontends
|
|
|
|
/// require some transformations for semantic reasons, they should explicitly
|
|
|
|
/// build them.
|
2017-07-07 22:53:10 +02:00
|
|
|
///
|
2017-07-30 06:55:39 +02:00
|
|
|
/// \p Phase indicates the current ThinLTO phase.
|
2017-06-01 13:39:39 +02:00
|
|
|
ModulePassManager
|
|
|
|
buildModuleSimplificationPipeline(OptimizationLevel Level,
|
2017-07-30 06:55:39 +02:00
|
|
|
ThinLTOPhase Phase,
|
|
|
|
bool DebugLogging = false);
|
2017-06-01 13:39:39 +02:00
|
|
|
|
|
|
|
/// Construct the core LLVM module optimization pipeline.
|
|
|
|
///
|
|
|
|
/// This pipeline focuses on optimizing the execution speed of the IR. It
|
|
|
|
/// uses cost modeling and thresholds to balance code growth against runtime
|
|
|
|
/// improvements. It includes vectorization and other information destroying
|
|
|
|
/// transformations. It also cannot generally be run repeatedly on a module
|
|
|
|
/// without potentially seriously regressing either runtime performance of
|
|
|
|
/// the code or serious code size growth.
|
|
|
|
///
|
|
|
|
/// Note that \p Level cannot be `O0` here. The pipelines produced are
|
|
|
|
/// only intended for use when attempting to optimize code. If frontends
|
|
|
|
/// require some transformations for semantic reasons, they should explicitly
|
|
|
|
/// build them.
|
|
|
|
ModulePassManager buildModuleOptimizationPipeline(OptimizationLevel Level,
|
|
|
|
bool DebugLogging = false);
|
|
|
|
|
2016-12-22 07:59:15 +01:00
|
|
|
/// Build a per-module default optimization pipeline.
|
2016-02-28 23:16:03 +01:00
|
|
|
///
|
|
|
|
/// This provides a good default optimization pipeline for per-module
|
|
|
|
/// optimization and code generation without any link-time optimization. It
|
|
|
|
/// typically correspond to frontend "-O[123]" options for optimization
|
|
|
|
/// levels \c O1, \c O2 and \c O3 resp.
|
2016-12-22 07:59:15 +01:00
|
|
|
///
|
|
|
|
/// Note that \p Level cannot be `O0` here. The pipelines produced are
|
|
|
|
/// only intended for use when attempting to optimize code. If frontends
|
|
|
|
/// require some transformations for semantic reasons, they should explicitly
|
|
|
|
/// build them.
|
|
|
|
ModulePassManager buildPerModuleDefaultPipeline(OptimizationLevel Level,
|
|
|
|
bool DebugLogging = false);
|
|
|
|
|
2017-06-01 13:39:39 +02:00
|
|
|
/// Build a pre-link, ThinLTO-targeting default optimization pipeline to
|
|
|
|
/// a pass manager.
|
|
|
|
///
|
|
|
|
/// This adds the pre-link optimizations tuned to prepare a module for
|
|
|
|
/// a ThinLTO run. It works to minimize the IR which needs to be analyzed
|
|
|
|
/// without making irreversible decisions which could be made better during
|
|
|
|
/// the LTO run.
|
|
|
|
///
|
|
|
|
/// Note that \p Level cannot be `O0` here. The pipelines produced are
|
|
|
|
/// only intended for use when attempting to optimize code. If frontends
|
|
|
|
/// require some transformations for semantic reasons, they should explicitly
|
|
|
|
/// build them.
|
|
|
|
ModulePassManager
|
|
|
|
buildThinLTOPreLinkDefaultPipeline(OptimizationLevel Level,
|
|
|
|
bool DebugLogging = false);
|
|
|
|
|
|
|
|
/// Build an ThinLTO default optimization pipeline to a pass manager.
|
|
|
|
///
|
|
|
|
/// This provides a good default optimization pipeline for link-time
|
|
|
|
/// optimization and code generation. It is particularly tuned to fit well
|
|
|
|
/// when IR coming into the LTO phase was first run through \c
|
|
|
|
/// addPreLinkLTODefaultPipeline, and the two coordinate closely.
|
|
|
|
///
|
|
|
|
/// Note that \p Level cannot be `O0` here. The pipelines produced are
|
|
|
|
/// only intended for use when attempting to optimize code. If frontends
|
|
|
|
/// require some transformations for semantic reasons, they should explicitly
|
|
|
|
/// build them.
|
2018-07-19 16:51:32 +02:00
|
|
|
ModulePassManager
|
|
|
|
buildThinLTODefaultPipeline(OptimizationLevel Level, bool DebugLogging,
|
|
|
|
const ModuleSummaryIndex *ImportSummary);
|
2017-06-01 13:39:39 +02:00
|
|
|
|
2016-12-22 07:59:15 +01:00
|
|
|
/// Build a pre-link, LTO-targeting default optimization pipeline to a pass
|
|
|
|
/// manager.
|
2016-02-28 23:16:03 +01:00
|
|
|
///
|
|
|
|
/// This adds the pre-link optimizations tuned to work well with a later LTO
|
|
|
|
/// run. It works to minimize the IR which needs to be analyzed without
|
|
|
|
/// making irreversible decisions which could be made better during the LTO
|
|
|
|
/// run.
|
2016-12-22 07:59:15 +01:00
|
|
|
///
|
|
|
|
/// Note that \p Level cannot be `O0` here. The pipelines produced are
|
|
|
|
/// only intended for use when attempting to optimize code. If frontends
|
|
|
|
/// require some transformations for semantic reasons, they should explicitly
|
|
|
|
/// build them.
|
|
|
|
ModulePassManager buildLTOPreLinkDefaultPipeline(OptimizationLevel Level,
|
|
|
|
bool DebugLogging = false);
|
|
|
|
|
|
|
|
/// Build an LTO default optimization pipeline to a pass manager.
|
2016-02-28 23:16:03 +01:00
|
|
|
///
|
|
|
|
/// This provides a good default optimization pipeline for link-time
|
|
|
|
/// optimization and code generation. It is particularly tuned to fit well
|
|
|
|
/// when IR coming into the LTO phase was first run through \c
|
|
|
|
/// addPreLinkLTODefaultPipeline, and the two coordinate closely.
|
2016-12-22 07:59:15 +01:00
|
|
|
///
|
|
|
|
/// Note that \p Level cannot be `O0` here. The pipelines produced are
|
|
|
|
/// only intended for use when attempting to optimize code. If frontends
|
|
|
|
/// require some transformations for semantic reasons, they should explicitly
|
|
|
|
/// build them.
|
|
|
|
ModulePassManager buildLTODefaultPipeline(OptimizationLevel Level,
|
2018-07-19 16:51:32 +02:00
|
|
|
bool DebugLogging,
|
|
|
|
ModuleSummaryIndex *ExportSummary);
|
2016-02-28 23:16:03 +01:00
|
|
|
|
2016-12-23 21:38:19 +01:00
|
|
|
/// Build the default `AAManager` with the default alias analysis pipeline
|
|
|
|
/// registered.
|
|
|
|
AAManager buildDefaultAAPipeline();
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Parse a textual pass pipeline description into a \c
|
[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
|
|
|
/// ModulePassManager.
|
2015-02-01 08:40:05 +01:00
|
|
|
///
|
|
|
|
/// The format of the textual pass pipeline description looks something like:
|
|
|
|
///
|
|
|
|
/// module(function(instcombine,sroa),dce,cgscc(inliner,function(...)),...)
|
|
|
|
///
|
|
|
|
/// Pass managers have ()s describing the nest structure of passes. All passes
|
|
|
|
/// are comma separated. As a special shortcut, if the very first pass is not
|
|
|
|
/// a module pass (as a module pass manager is), this will automatically form
|
|
|
|
/// the shortest stack of pass managers that allow inserting that first pass.
|
[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
|
|
|
/// So, assuming function passes 'fpassN', CGSCC passes 'cgpassN', and loop
|
|
|
|
/// passes 'lpassN', all of these are valid:
|
2015-02-01 08:40:05 +01:00
|
|
|
///
|
|
|
|
/// fpass1,fpass2,fpass3
|
|
|
|
/// cgpass1,cgpass2,cgpass3
|
|
|
|
/// lpass1,lpass2,lpass3
|
|
|
|
///
|
|
|
|
/// And they are equivalent to the following (resp.):
|
|
|
|
///
|
|
|
|
/// module(function(fpass1,fpass2,fpass3))
|
|
|
|
/// module(cgscc(cgpass1,cgpass2,cgpass3))
|
|
|
|
/// module(function(loop(lpass1,lpass2,lpass3)))
|
|
|
|
///
|
|
|
|
/// This shortcut is especially useful for debugging and testing small pass
|
[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
|
|
|
/// combinations. Note that these shortcuts don't introduce any other magic.
|
|
|
|
/// If the sequence of passes aren't all the exact same kind of pass, it will
|
|
|
|
/// be an error. You cannot mix different levels implicitly, you must
|
|
|
|
/// explicitly form a pass manager in which to nest passes.
|
2015-02-01 08:40:05 +01:00
|
|
|
bool parsePassPipeline(ModulePassManager &MPM, StringRef PipelineText,
|
|
|
|
bool VerifyEachPass = true, bool DebugLogging = false);
|
|
|
|
|
[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
|
|
|
/// {{@ Parse a textual pass pipeline description into a specific PassManager
|
|
|
|
///
|
|
|
|
/// Automatic deduction of an appropriate pass manager stack is not supported.
|
|
|
|
/// For example, to insert a loop pass 'lpass' into a FunctinoPassManager,
|
|
|
|
/// this is the valid pipeline text:
|
|
|
|
///
|
|
|
|
/// function(lpass)
|
|
|
|
bool parsePassPipeline(CGSCCPassManager &CGPM, StringRef PipelineText,
|
|
|
|
bool VerifyEachPass = true, bool DebugLogging = false);
|
|
|
|
bool parsePassPipeline(FunctionPassManager &FPM, StringRef PipelineText,
|
|
|
|
bool VerifyEachPass = true, bool DebugLogging = false);
|
|
|
|
bool parsePassPipeline(LoopPassManager &LPM, StringRef PipelineText,
|
|
|
|
bool VerifyEachPass = true, bool DebugLogging = false);
|
|
|
|
/// @}}
|
|
|
|
|
2016-02-18 10:45:17 +01:00
|
|
|
/// Parse a textual alias analysis pipeline into the provided AA manager.
|
|
|
|
///
|
|
|
|
/// The format of the textual AA pipeline is a comma separated list of AA
|
|
|
|
/// pass names:
|
|
|
|
///
|
|
|
|
/// basic-aa,globals-aa,...
|
|
|
|
///
|
|
|
|
/// The AA manager is set up such that the provided alias analyses are tried
|
|
|
|
/// in the order specified. See the \c AAManaager documentation for details
|
|
|
|
/// about the logic used. This routine just provides the textual mapping
|
|
|
|
/// between AA names and the analyses to register with the manager.
|
|
|
|
///
|
|
|
|
/// Returns false if the text cannot be parsed cleanly. The specific state of
|
|
|
|
/// the \p AA manager is unspecified if such an error is encountered and this
|
|
|
|
/// returns false.
|
|
|
|
bool parseAAPipeline(AAManager &AA, StringRef PipelineText);
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Register a callback for a default optimizer pipeline extension
|
[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
|
|
|
/// point
|
|
|
|
///
|
|
|
|
/// This extension point allows adding passes that perform peephole
|
|
|
|
/// optimizations similar to the instruction combiner. These passes will be
|
|
|
|
/// inserted after each instance of the instruction combiner pass.
|
|
|
|
void registerPeepholeEPCallback(
|
|
|
|
const std::function<void(FunctionPassManager &, OptimizationLevel)> &C) {
|
|
|
|
PeepholeEPCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Register a callback for a default optimizer pipeline extension
|
[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
|
|
|
/// point
|
|
|
|
///
|
|
|
|
/// This extension point allows adding late loop canonicalization and
|
|
|
|
/// simplification passes. This is the last point in the loop optimization
|
|
|
|
/// pipeline before loop deletion. Each pass added
|
|
|
|
/// here must be an instance of LoopPass.
|
|
|
|
/// This is the place to add passes that can remove loops, such as target-
|
|
|
|
/// specific loop idiom recognition.
|
|
|
|
void registerLateLoopOptimizationsEPCallback(
|
|
|
|
const std::function<void(LoopPassManager &, OptimizationLevel)> &C) {
|
|
|
|
LateLoopOptimizationsEPCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Register a callback for a default optimizer pipeline extension
|
[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
|
|
|
/// point
|
|
|
|
///
|
|
|
|
/// This extension point allows adding loop passes to the end of the loop
|
|
|
|
/// optimizer.
|
|
|
|
void registerLoopOptimizerEndEPCallback(
|
|
|
|
const std::function<void(LoopPassManager &, OptimizationLevel)> &C) {
|
|
|
|
LoopOptimizerEndEPCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Register a callback for a default optimizer pipeline extension
|
[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
|
|
|
/// point
|
|
|
|
///
|
|
|
|
/// This extension point allows adding optimization passes after most of the
|
|
|
|
/// main optimizations, but before the last cleanup-ish optimizations.
|
|
|
|
void registerScalarOptimizerLateEPCallback(
|
|
|
|
const std::function<void(FunctionPassManager &, OptimizationLevel)> &C) {
|
|
|
|
ScalarOptimizerLateEPCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Register a callback for a default optimizer pipeline extension
|
[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
|
|
|
/// point
|
|
|
|
///
|
|
|
|
/// This extension point allows adding CallGraphSCC passes at the end of the
|
|
|
|
/// main CallGraphSCC passes and before any function simplification passes run
|
|
|
|
/// by CGPassManager.
|
|
|
|
void registerCGSCCOptimizerLateEPCallback(
|
|
|
|
const std::function<void(CGSCCPassManager &, OptimizationLevel)> &C) {
|
|
|
|
CGSCCOptimizerLateEPCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Register a callback for a default optimizer pipeline extension
|
[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
|
|
|
/// point
|
|
|
|
///
|
|
|
|
/// This extension point allows adding optimization passes before the
|
|
|
|
/// vectorizer and other highly target specific optimization passes are
|
|
|
|
/// executed.
|
|
|
|
void registerVectorizerStartEPCallback(
|
|
|
|
const std::function<void(FunctionPassManager &, OptimizationLevel)> &C) {
|
|
|
|
VectorizerStartEPCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
|
2018-01-23 02:25:20 +01:00
|
|
|
/// Register a callback for a default optimizer pipeline extension point.
|
|
|
|
///
|
|
|
|
/// This extension point allows adding optimization once at the start of the
|
|
|
|
/// pipeline. This does not apply to 'backend' compiles (LTO and ThinLTO
|
|
|
|
/// link-time pipelines).
|
|
|
|
void registerPipelineStartEPCallback(
|
|
|
|
const std::function<void(ModulePassManager &)> &C) {
|
|
|
|
PipelineStartEPCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Register a callback for parsing an AliasAnalysis Name to populate
|
[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
|
|
|
/// the given AAManager \p AA
|
|
|
|
void registerParseAACallback(
|
|
|
|
const std::function<bool(StringRef Name, AAManager &AA)> &C) {
|
|
|
|
AAParsingCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// {{@ Register callbacks for analysis registration with this PassBuilder
|
|
|
|
/// instance.
|
|
|
|
/// Callees register their analyses with the given AnalysisManager objects.
|
|
|
|
void registerAnalysisRegistrationCallback(
|
|
|
|
const std::function<void(CGSCCAnalysisManager &)> &C) {
|
|
|
|
CGSCCAnalysisRegistrationCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
void registerAnalysisRegistrationCallback(
|
|
|
|
const std::function<void(FunctionAnalysisManager &)> &C) {
|
|
|
|
FunctionAnalysisRegistrationCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
void registerAnalysisRegistrationCallback(
|
|
|
|
const std::function<void(LoopAnalysisManager &)> &C) {
|
|
|
|
LoopAnalysisRegistrationCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
void registerAnalysisRegistrationCallback(
|
|
|
|
const std::function<void(ModuleAnalysisManager &)> &C) {
|
|
|
|
ModuleAnalysisRegistrationCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
/// @}}
|
|
|
|
|
|
|
|
/// {{@ Register pipeline parsing callbacks with this pass builder instance.
|
|
|
|
/// Using these callbacks, callers can parse both a single pass name, as well
|
|
|
|
/// as entire sub-pipelines, and populate the PassManager instance
|
|
|
|
/// accordingly.
|
|
|
|
void registerPipelineParsingCallback(
|
|
|
|
const std::function<bool(StringRef Name, CGSCCPassManager &,
|
|
|
|
ArrayRef<PipelineElement>)> &C) {
|
|
|
|
CGSCCPipelineParsingCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
void registerPipelineParsingCallback(
|
|
|
|
const std::function<bool(StringRef Name, FunctionPassManager &,
|
|
|
|
ArrayRef<PipelineElement>)> &C) {
|
|
|
|
FunctionPipelineParsingCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
void registerPipelineParsingCallback(
|
|
|
|
const std::function<bool(StringRef Name, LoopPassManager &,
|
|
|
|
ArrayRef<PipelineElement>)> &C) {
|
|
|
|
LoopPipelineParsingCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
void registerPipelineParsingCallback(
|
|
|
|
const std::function<bool(StringRef Name, ModulePassManager &,
|
|
|
|
ArrayRef<PipelineElement>)> &C) {
|
|
|
|
ModulePipelineParsingCallbacks.push_back(C);
|
|
|
|
}
|
|
|
|
/// @}}
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Register a callback for a top-level pipeline entry.
|
[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 the PassManager type is not given at the top level of the pipeline
|
|
|
|
/// text, this Callback should be used to determine the appropriate stack of
|
|
|
|
/// PassManagers and populate the passed ModulePassManager.
|
|
|
|
void registerParseTopLevelPipelineCallback(
|
|
|
|
const std::function<bool(ModulePassManager &, ArrayRef<PipelineElement>,
|
|
|
|
bool VerifyEachPass, bool DebugLogging)> &C) {
|
|
|
|
TopLevelPipelineParsingCallbacks.push_back(C);
|
|
|
|
}
|
2016-08-03 05:21:41 +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
|
|
|
private:
|
2016-08-03 05:21:41 +02:00
|
|
|
static Optional<std::vector<PipelineElement>>
|
|
|
|
parsePipelineText(StringRef Text);
|
|
|
|
|
|
|
|
bool parseModulePass(ModulePassManager &MPM, const PipelineElement &E,
|
|
|
|
bool VerifyEachPass, bool DebugLogging);
|
|
|
|
bool parseCGSCCPass(CGSCCPassManager &CGPM, const PipelineElement &E,
|
|
|
|
bool VerifyEachPass, bool DebugLogging);
|
|
|
|
bool parseFunctionPass(FunctionPassManager &FPM, const PipelineElement &E,
|
|
|
|
bool VerifyEachPass, bool DebugLogging);
|
|
|
|
bool parseLoopPass(LoopPassManager &LPM, const PipelineElement &E,
|
|
|
|
bool VerifyEachPass, bool DebugLogging);
|
2016-02-18 10:45:17 +01:00
|
|
|
bool parseAAPassName(AAManager &AA, StringRef Name);
|
2016-08-03 05:21:41 +02:00
|
|
|
|
|
|
|
bool parseLoopPassPipeline(LoopPassManager &LPM,
|
|
|
|
ArrayRef<PipelineElement> Pipeline,
|
2016-02-25 08:23:08 +01:00
|
|
|
bool VerifyEachPass, bool DebugLogging);
|
2015-02-01 08:40:05 +01:00
|
|
|
bool parseFunctionPassPipeline(FunctionPassManager &FPM,
|
2016-08-03 05:21:41 +02:00
|
|
|
ArrayRef<PipelineElement> Pipeline,
|
|
|
|
bool VerifyEachPass, bool DebugLogging);
|
|
|
|
bool parseCGSCCPassPipeline(CGSCCPassManager &CGPM,
|
|
|
|
ArrayRef<PipelineElement> Pipeline,
|
2015-02-01 08:40:05 +01:00
|
|
|
bool VerifyEachPass, bool DebugLogging);
|
2016-08-03 05:21:41 +02:00
|
|
|
bool parseModulePassPipeline(ModulePassManager &MPM,
|
|
|
|
ArrayRef<PipelineElement> Pipeline,
|
2015-02-01 08:40:05 +01:00
|
|
|
bool VerifyEachPass, bool 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 12:57:55 +02:00
|
|
|
|
|
|
|
void addPGOInstrPasses(ModulePassManager &MPM, bool DebugLogging,
|
|
|
|
OptimizationLevel Level, bool RunProfileGen,
|
|
|
|
std::string ProfileGenFile,
|
|
|
|
std::string ProfileUseFile);
|
|
|
|
|
|
|
|
void invokePeepholeEPCallbacks(FunctionPassManager &, OptimizationLevel);
|
|
|
|
|
|
|
|
// Extension Point callbacks
|
|
|
|
SmallVector<std::function<void(FunctionPassManager &, OptimizationLevel)>, 2>
|
|
|
|
PeepholeEPCallbacks;
|
|
|
|
SmallVector<std::function<void(LoopPassManager &, OptimizationLevel)>, 2>
|
|
|
|
LateLoopOptimizationsEPCallbacks;
|
|
|
|
SmallVector<std::function<void(LoopPassManager &, OptimizationLevel)>, 2>
|
|
|
|
LoopOptimizerEndEPCallbacks;
|
|
|
|
SmallVector<std::function<void(FunctionPassManager &, OptimizationLevel)>, 2>
|
|
|
|
ScalarOptimizerLateEPCallbacks;
|
|
|
|
SmallVector<std::function<void(CGSCCPassManager &, OptimizationLevel)>, 2>
|
|
|
|
CGSCCOptimizerLateEPCallbacks;
|
|
|
|
SmallVector<std::function<void(FunctionPassManager &, OptimizationLevel)>, 2>
|
|
|
|
VectorizerStartEPCallbacks;
|
|
|
|
// Module callbacks
|
2018-01-23 02:25:20 +01:00
|
|
|
SmallVector<std::function<void(ModulePassManager &)>, 2>
|
|
|
|
PipelineStartEPCallbacks;
|
[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
|
|
|
SmallVector<std::function<void(ModuleAnalysisManager &)>, 2>
|
|
|
|
ModuleAnalysisRegistrationCallbacks;
|
|
|
|
SmallVector<std::function<bool(StringRef, ModulePassManager &,
|
|
|
|
ArrayRef<PipelineElement>)>,
|
|
|
|
2>
|
|
|
|
ModulePipelineParsingCallbacks;
|
|
|
|
SmallVector<std::function<bool(ModulePassManager &, ArrayRef<PipelineElement>,
|
|
|
|
bool VerifyEachPass, bool DebugLogging)>,
|
|
|
|
2>
|
|
|
|
TopLevelPipelineParsingCallbacks;
|
|
|
|
// CGSCC callbacks
|
|
|
|
SmallVector<std::function<void(CGSCCAnalysisManager &)>, 2>
|
|
|
|
CGSCCAnalysisRegistrationCallbacks;
|
|
|
|
SmallVector<std::function<bool(StringRef, CGSCCPassManager &,
|
|
|
|
ArrayRef<PipelineElement>)>,
|
|
|
|
2>
|
|
|
|
CGSCCPipelineParsingCallbacks;
|
|
|
|
// Function callbacks
|
|
|
|
SmallVector<std::function<void(FunctionAnalysisManager &)>, 2>
|
|
|
|
FunctionAnalysisRegistrationCallbacks;
|
|
|
|
SmallVector<std::function<bool(StringRef, FunctionPassManager &,
|
|
|
|
ArrayRef<PipelineElement>)>,
|
|
|
|
2>
|
|
|
|
FunctionPipelineParsingCallbacks;
|
|
|
|
// Loop callbacks
|
|
|
|
SmallVector<std::function<void(LoopAnalysisManager &)>, 2>
|
|
|
|
LoopAnalysisRegistrationCallbacks;
|
|
|
|
SmallVector<std::function<bool(StringRef, LoopPassManager &,
|
|
|
|
ArrayRef<PipelineElement>)>,
|
|
|
|
2>
|
|
|
|
LoopPipelineParsingCallbacks;
|
|
|
|
// AA callbacks
|
|
|
|
SmallVector<std::function<bool(StringRef Name, AAManager &AA)>, 2>
|
|
|
|
AAParsingCallbacks;
|
2015-02-01 08:40:05 +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
|
|
|
|
|
|
|
/// This utility template takes care of adding require<> and invalidate<>
|
|
|
|
/// passes for an analysis to a given \c PassManager. It is intended to be used
|
|
|
|
/// during parsing of a pass pipeline when parsing a single PipelineName.
|
|
|
|
/// When registering a new function analysis FancyAnalysis with the pass
|
|
|
|
/// pipeline name "fancy-analysis", a matching ParsePipelineCallback could look
|
|
|
|
/// like this:
|
|
|
|
///
|
|
|
|
/// static bool parseFunctionPipeline(StringRef Name, FunctionPassManager &FPM,
|
|
|
|
/// ArrayRef<PipelineElement> P) {
|
|
|
|
/// if (parseAnalysisUtilityPasses<FancyAnalysis>("fancy-analysis", Name,
|
|
|
|
/// FPM))
|
|
|
|
/// return true;
|
|
|
|
/// return false;
|
|
|
|
/// }
|
|
|
|
template <typename AnalysisT, typename IRUnitT, typename AnalysisManagerT,
|
|
|
|
typename... ExtraArgTs>
|
|
|
|
bool parseAnalysisUtilityPasses(
|
|
|
|
StringRef AnalysisName, StringRef PipelineName,
|
|
|
|
PassManager<IRUnitT, AnalysisManagerT, ExtraArgTs...> &PM) {
|
|
|
|
if (!PipelineName.endswith(">"))
|
|
|
|
return false;
|
|
|
|
// See if this is an invalidate<> pass name
|
|
|
|
if (PipelineName.startswith("invalidate<")) {
|
|
|
|
PipelineName = PipelineName.substr(11, PipelineName.size() - 12);
|
|
|
|
if (PipelineName != AnalysisName)
|
|
|
|
return false;
|
|
|
|
PM.addPass(InvalidateAnalysisPass<AnalysisT>());
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// See if this is a require<> pass name
|
|
|
|
if (PipelineName.startswith("require<")) {
|
|
|
|
PipelineName = PipelineName.substr(8, PipelineName.size() - 9);
|
|
|
|
if (PipelineName != AnalysisName)
|
|
|
|
return false;
|
|
|
|
PM.addPass(RequireAnalysisPass<AnalysisT, IRUnitT, AnalysisManagerT,
|
|
|
|
ExtraArgTs...>());
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
2015-06-23 11:49:53 +02:00
|
|
|
}
|
[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
|
|
|
|
|
|
|
#endif
|