summaryrefslogtreecommitdiff
path: root/include/llvm/Passes/PassBuilder.h
diff options
context:
space:
mode:
authorDimitry Andric <dim@FreeBSD.org>2017-06-01 20:58:36 +0000
committerDimitry Andric <dim@FreeBSD.org>2017-06-01 20:58:36 +0000
commitf382538d471e38a9b98f016c4caebd24c8d60b62 (patch)
treed30f3d58b1044b5355d50c17a6a96c6a0b35703a /include/llvm/Passes/PassBuilder.h
parentee2f195dd3e40f49698ca4dc2666ec09c770e80d (diff)
Notes
Diffstat (limited to 'include/llvm/Passes/PassBuilder.h')
-rw-r--r--include/llvm/Passes/PassBuilder.h63
1 files changed, 63 insertions, 0 deletions
diff --git a/include/llvm/Passes/PassBuilder.h b/include/llvm/Passes/PassBuilder.h
index efa36d957fbd..12b05e4ff0c5 100644
--- a/include/llvm/Passes/PassBuilder.h
+++ b/include/llvm/Passes/PassBuilder.h
@@ -192,6 +192,39 @@ public:
buildFunctionSimplificationPipeline(OptimizationLevel Level,
bool DebugLogging = false);
+ /// 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.
+ ModulePassManager
+ buildModuleSimplificationPipeline(OptimizationLevel Level,
+ bool DebugLogging = false);
+
+ /// 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);
+
/// Build a per-module default optimization pipeline.
///
/// This provides a good default optimization pipeline for per-module
@@ -206,6 +239,36 @@ public:
ModulePassManager buildPerModuleDefaultPipeline(OptimizationLevel Level,
bool DebugLogging = false);
+ /// 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.
+ ModulePassManager buildThinLTODefaultPipeline(OptimizationLevel Level,
+ bool DebugLogging = false);
+
/// Build a pre-link, LTO-targeting default optimization pipeline to a pass
/// manager.
///