blob: 9c915c61b96400e727d9177939f09cf5384e326a [file] [log] [blame]
Yi Kong7bf2a682019-04-18 17:30:49 -07001//===- Parsing, selection, and construction of pass pipelines --*- C++ -*--===//
2//
3// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
4// See https://llvm.org/LICENSE.txt for license information.
5// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
6//
7//===----------------------------------------------------------------------===//
8/// \file
9///
10/// Interfaces for registering analysis passes, producing common pass manager
11/// configurations, and parsing of pass pipelines.
12///
13//===----------------------------------------------------------------------===//
14
15#ifndef LLVM_PASSES_PASSBUILDER_H
16#define LLVM_PASSES_PASSBUILDER_H
17
18#include "llvm/ADT/Optional.h"
19#include "llvm/Analysis/CGSCCPassManager.h"
20#include "llvm/IR/PassManager.h"
21#include "llvm/Support/Error.h"
22#include "llvm/Transforms/Instrumentation.h"
23#include "llvm/Transforms/Scalar/LoopPassManager.h"
24#include <vector>
25
26namespace llvm {
27class StringRef;
28class AAManager;
29class TargetMachine;
30class ModuleSummaryIndex;
31
32/// A struct capturing PGO tunables.
33struct PGOOptions {
34 PGOOptions(std::string ProfileGenFile = "", std::string ProfileUseFile = "",
35 std::string SampleProfileFile = "",
36 std::string ProfileRemappingFile = "",
37 bool RunProfileGen = false, bool SamplePGOSupport = false)
38 : ProfileGenFile(ProfileGenFile), ProfileUseFile(ProfileUseFile),
39 SampleProfileFile(SampleProfileFile),
40 ProfileRemappingFile(ProfileRemappingFile),
41 RunProfileGen(RunProfileGen),
42 SamplePGOSupport(SamplePGOSupport || !SampleProfileFile.empty()) {
43 assert((RunProfileGen ||
44 !SampleProfileFile.empty() ||
45 !ProfileUseFile.empty() ||
46 SamplePGOSupport) && "Illegal PGOOptions.");
47 }
48 std::string ProfileGenFile;
49 std::string ProfileUseFile;
50 std::string SampleProfileFile;
51 std::string ProfileRemappingFile;
52 bool RunProfileGen;
53 bool SamplePGOSupport;
54};
55
56/// This class provides access to building LLVM's passes.
57///
58/// Its members provide the baseline state available to passes during their
59/// construction. The \c PassRegistry.def file specifies how to construct all
60/// of the built-in passes, and those may reference these members during
61/// construction.
62class PassBuilder {
63 TargetMachine *TM;
64 Optional<PGOOptions> PGOOpt;
65 PassInstrumentationCallbacks *PIC;
66
67public:
68 /// A struct to capture parsed pass pipeline names.
69 ///
70 /// A pipeline is defined as a series of names, each of which may in itself
71 /// recursively contain a nested pipeline. A name is either the name of a pass
72 /// (e.g. "instcombine") or the name of a pipeline type (e.g. "cgscc"). If the
73 /// name is the name of a pass, the InnerPipeline is empty, since passes
74 /// cannot contain inner pipelines. See parsePassPipeline() for a more
75 /// detailed description of the textual pipeline format.
76 struct PipelineElement {
77 StringRef Name;
78 std::vector<PipelineElement> InnerPipeline;
79 };
80
81 /// ThinLTO phase.
82 ///
83 /// This enumerates the LLVM ThinLTO optimization phases.
84 enum class ThinLTOPhase {
85 /// No ThinLTO behavior needed.
86 None,
87 // ThinLTO prelink (summary) phase.
88 PreLink,
89 // ThinLTO postlink (backend compile) phase.
90 PostLink
91 };
92
93 /// LLVM-provided high-level optimization levels.
94 ///
95 /// This enumerates the LLVM-provided high-level optimization levels. Each
96 /// level has a specific goal and rationale.
97 enum OptimizationLevel {
98 /// Disable as many optimizations as possible. This doesn't completely
99 /// disable the optimizer in all cases, for example always_inline functions
100 /// can be required to be inlined for correctness.
101 O0,
102
103 /// Optimize quickly without destroying debuggability.
104 ///
105 /// FIXME: The current and historical behavior of this level does *not*
106 /// agree with this goal, but we would like to move toward this goal in the
107 /// future.
108 ///
109 /// This level is tuned to produce a result from the optimizer as quickly
110 /// as possible and to avoid destroying debuggability. This tends to result
111 /// in a very good development mode where the compiled code will be
112 /// immediately executed as part of testing. As a consequence, where
113 /// possible, we would like to produce efficient-to-execute code, but not
114 /// if it significantly slows down compilation or would prevent even basic
115 /// debugging of the resulting binary.
116 ///
117 /// As an example, complex loop transformations such as versioning,
118 /// vectorization, or fusion might not make sense here due to the degree to
119 /// which the executed code would differ from the source code, and the
120 /// potential compile time cost.
121 O1,
122
123 /// Optimize for fast execution as much as possible without triggering
124 /// significant incremental compile time or code size growth.
125 ///
126 /// The key idea is that optimizations at this level should "pay for
127 /// themselves". So if an optimization increases compile time by 5% or
128 /// increases code size by 5% for a particular benchmark, that benchmark
129 /// should also be one which sees a 5% runtime improvement. If the compile
130 /// time or code size penalties happen on average across a diverse range of
131 /// LLVM users' benchmarks, then the improvements should as well.
132 ///
133 /// And no matter what, the compile time needs to not grow superlinearly
134 /// with the size of input to LLVM so that users can control the runtime of
135 /// the optimizer in this mode.
136 ///
137 /// This is expected to be a good default optimization level for the vast
138 /// majority of users.
139 O2,
140
141 /// Optimize for fast execution as much as possible.
142 ///
143 /// This mode is significantly more aggressive in trading off compile time
144 /// and code size to get execution time improvements. The core idea is that
145 /// this mode should include any optimization that helps execution time on
146 /// balance across a diverse collection of benchmarks, even if it increases
147 /// code size or compile time for some benchmarks without corresponding
148 /// improvements to execution time.
149 ///
150 /// Despite being willing to trade more compile time off to get improved
151 /// execution time, this mode still tries to avoid superlinear growth in
152 /// order to make even significantly slower compile times at least scale
153 /// reasonably. This does not preclude very substantial constant factor
154 /// costs though.
155 O3,
156
157 /// Similar to \c O2 but tries to optimize for small code size instead of
158 /// fast execution without triggering significant incremental execution
159 /// time slowdowns.
160 ///
161 /// The logic here is exactly the same as \c O2, but with code size and
162 /// execution time metrics swapped.
163 ///
164 /// A consequence of the different core goal is that this should in general
165 /// produce substantially smaller executables that still run in
166 /// a reasonable amount of time.
167 Os,
168
169 /// A very specialized mode that will optimize for code size at any and all
170 /// costs.
171 ///
172 /// This is useful primarily when there are absolute size limitations and
173 /// any effort taken to reduce the size is worth it regardless of the
174 /// execution time impact. You should expect this level to produce rather
175 /// slow, but very small, code.
176 Oz
177 };
178
179 explicit PassBuilder(TargetMachine *TM = nullptr,
180 Optional<PGOOptions> PGOOpt = None,
181 PassInstrumentationCallbacks *PIC = nullptr)
182 : TM(TM), PGOOpt(PGOOpt), PIC(PIC) {}
183
184 /// Cross register the analysis managers through their proxies.
185 ///
186 /// This is an interface that can be used to cross register each
187 // AnalysisManager with all the others analysis managers.
188 void crossRegisterProxies(LoopAnalysisManager &LAM,
189 FunctionAnalysisManager &FAM,
190 CGSCCAnalysisManager &CGAM,
191 ModuleAnalysisManager &MAM);
192
193 /// Registers all available module analysis passes.
194 ///
195 /// This is an interface that can be used to populate a \c
196 /// ModuleAnalysisManager with all registered module analyses. Callers can
197 /// still manually register any additional analyses. Callers can also
198 /// pre-register analyses and this will not override those.
199 void registerModuleAnalyses(ModuleAnalysisManager &MAM);
200
201 /// Registers all available CGSCC analysis passes.
202 ///
203 /// This is an interface that can be used to populate a \c CGSCCAnalysisManager
204 /// with all registered CGSCC analyses. Callers can still manually register any
205 /// additional analyses. Callers can also pre-register analyses and this will
206 /// not override those.
207 void registerCGSCCAnalyses(CGSCCAnalysisManager &CGAM);
208
209 /// Registers all available function analysis passes.
210 ///
211 /// This is an interface that can be used to populate a \c
212 /// FunctionAnalysisManager with all registered function analyses. Callers can
213 /// still manually register any additional analyses. Callers can also
214 /// pre-register analyses and this will not override those.
215 void registerFunctionAnalyses(FunctionAnalysisManager &FAM);
216
217 /// Registers all available loop analysis passes.
218 ///
219 /// This is an interface that can be used to populate a \c LoopAnalysisManager
220 /// with all registered loop analyses. Callers can still manually register any
221 /// additional analyses.
222 void registerLoopAnalyses(LoopAnalysisManager &LAM);
223
224 /// Construct the core LLVM function canonicalization and simplification
225 /// pipeline.
226 ///
227 /// This is a long pipeline and uses most of the per-function optimization
228 /// passes in LLVM to canonicalize and simplify the IR. It is suitable to run
229 /// repeatedly over the IR and is not expected to destroy important
230 /// information about the semantics of the IR.
231 ///
232 /// Note that \p Level cannot be `O0` here. The pipelines produced are
233 /// only intended for use when attempting to optimize code. If frontends
234 /// require some transformations for semantic reasons, they should explicitly
235 /// build them.
236 ///
237 /// \p Phase indicates the current ThinLTO phase.
238 FunctionPassManager
239 buildFunctionSimplificationPipeline(OptimizationLevel Level,
240 ThinLTOPhase Phase,
241 bool DebugLogging = false);
242
243 /// Construct the core LLVM module canonicalization and simplification
244 /// pipeline.
245 ///
246 /// This pipeline focuses on canonicalizing and simplifying the entire module
247 /// of IR. Much like the function simplification pipeline above, it is
248 /// suitable to run repeatedly over the IR and is not expected to destroy
249 /// important information. It does, however, perform inlining and other
250 /// heuristic based simplifications that are not strictly reversible.
251 ///
252 /// Note that \p Level cannot be `O0` here. The pipelines produced are
253 /// only intended for use when attempting to optimize code. If frontends
254 /// require some transformations for semantic reasons, they should explicitly
255 /// build them.
256 ///
257 /// \p Phase indicates the current ThinLTO phase.
258 ModulePassManager
259 buildModuleSimplificationPipeline(OptimizationLevel Level,
260 ThinLTOPhase Phase,
261 bool DebugLogging = false);
262
263 /// Construct the core LLVM module optimization pipeline.
264 ///
265 /// This pipeline focuses on optimizing the execution speed of the IR. It
266 /// uses cost modeling and thresholds to balance code growth against runtime
267 /// improvements. It includes vectorization and other information destroying
268 /// transformations. It also cannot generally be run repeatedly on a module
269 /// without potentially seriously regressing either runtime performance of
270 /// the code or serious code size growth.
271 ///
272 /// Note that \p Level cannot be `O0` here. The pipelines produced are
273 /// only intended for use when attempting to optimize code. If frontends
274 /// require some transformations for semantic reasons, they should explicitly
275 /// build them.
276 ModulePassManager buildModuleOptimizationPipeline(OptimizationLevel Level,
277 bool DebugLogging = false);
278
279 /// Build a per-module default optimization pipeline.
280 ///
281 /// This provides a good default optimization pipeline for per-module
282 /// optimization and code generation without any link-time optimization. It
283 /// typically correspond to frontend "-O[123]" options for optimization
284 /// levels \c O1, \c O2 and \c O3 resp.
285 ///
286 /// Note that \p Level cannot be `O0` here. The pipelines produced are
287 /// only intended for use when attempting to optimize code. If frontends
288 /// require some transformations for semantic reasons, they should explicitly
289 /// build them.
290 ModulePassManager buildPerModuleDefaultPipeline(OptimizationLevel Level,
291 bool DebugLogging = false);
292
293 /// Build a pre-link, ThinLTO-targeting default optimization pipeline to
294 /// a pass manager.
295 ///
296 /// This adds the pre-link optimizations tuned to prepare a module for
297 /// a ThinLTO run. It works to minimize the IR which needs to be analyzed
298 /// without making irreversible decisions which could be made better during
299 /// the LTO run.
300 ///
301 /// Note that \p Level cannot be `O0` here. The pipelines produced are
302 /// only intended for use when attempting to optimize code. If frontends
303 /// require some transformations for semantic reasons, they should explicitly
304 /// build them.
305 ModulePassManager
306 buildThinLTOPreLinkDefaultPipeline(OptimizationLevel Level,
307 bool DebugLogging = false);
308
309 /// Build an ThinLTO default optimization pipeline to a pass manager.
310 ///
311 /// This provides a good default optimization pipeline for link-time
312 /// optimization and code generation. It is particularly tuned to fit well
313 /// when IR coming into the LTO phase was first run through \c
314 /// addPreLinkLTODefaultPipeline, and the two coordinate closely.
315 ///
316 /// Note that \p Level cannot be `O0` here. The pipelines produced are
317 /// only intended for use when attempting to optimize code. If frontends
318 /// require some transformations for semantic reasons, they should explicitly
319 /// build them.
320 ModulePassManager
321 buildThinLTODefaultPipeline(OptimizationLevel Level, bool DebugLogging,
322 const ModuleSummaryIndex *ImportSummary);
323
324 /// Build a pre-link, LTO-targeting default optimization pipeline to a pass
325 /// manager.
326 ///
327 /// This adds the pre-link optimizations tuned to work well with a later LTO
328 /// run. It works to minimize the IR which needs to be analyzed without
329 /// making irreversible decisions which could be made better during the LTO
330 /// run.
331 ///
332 /// Note that \p Level cannot be `O0` here. The pipelines produced are
333 /// only intended for use when attempting to optimize code. If frontends
334 /// require some transformations for semantic reasons, they should explicitly
335 /// build them.
336 ModulePassManager buildLTOPreLinkDefaultPipeline(OptimizationLevel Level,
337 bool DebugLogging = false);
338
339 /// Build an LTO default optimization pipeline to a pass manager.
340 ///
341 /// This provides a good default optimization pipeline for link-time
342 /// optimization and code generation. It is particularly tuned to fit well
343 /// when IR coming into the LTO phase was first run through \c
344 /// addPreLinkLTODefaultPipeline, and the two coordinate closely.
345 ///
346 /// Note that \p Level cannot be `O0` here. The pipelines produced are
347 /// only intended for use when attempting to optimize code. If frontends
348 /// require some transformations for semantic reasons, they should explicitly
349 /// build them.
350 ModulePassManager buildLTODefaultPipeline(OptimizationLevel Level,
351 bool DebugLogging,
352 ModuleSummaryIndex *ExportSummary);
353
354 /// Build the default `AAManager` with the default alias analysis pipeline
355 /// registered.
356 AAManager buildDefaultAAPipeline();
357
358 /// Parse a textual pass pipeline description into a \c
359 /// ModulePassManager.
360 ///
361 /// The format of the textual pass pipeline description looks something like:
362 ///
363 /// module(function(instcombine,sroa),dce,cgscc(inliner,function(...)),...)
364 ///
365 /// Pass managers have ()s describing the nest structure of passes. All passes
366 /// are comma separated. As a special shortcut, if the very first pass is not
367 /// a module pass (as a module pass manager is), this will automatically form
368 /// the shortest stack of pass managers that allow inserting that first pass.
369 /// So, assuming function passes 'fpassN', CGSCC passes 'cgpassN', and loop
370 /// passes 'lpassN', all of these are valid:
371 ///
372 /// fpass1,fpass2,fpass3
373 /// cgpass1,cgpass2,cgpass3
374 /// lpass1,lpass2,lpass3
375 ///
376 /// And they are equivalent to the following (resp.):
377 ///
378 /// module(function(fpass1,fpass2,fpass3))
379 /// module(cgscc(cgpass1,cgpass2,cgpass3))
380 /// module(function(loop(lpass1,lpass2,lpass3)))
381 ///
382 /// This shortcut is especially useful for debugging and testing small pass
383 /// combinations. Note that these shortcuts don't introduce any other magic.
384 /// If the sequence of passes aren't all the exact same kind of pass, it will
385 /// be an error. You cannot mix different levels implicitly, you must
386 /// explicitly form a pass manager in which to nest passes.
387 Error parsePassPipeline(ModulePassManager &MPM, StringRef PipelineText,
388 bool VerifyEachPass = true,
389 bool DebugLogging = false);
390
391 /// {{@ Parse a textual pass pipeline description into a specific PassManager
392 ///
393 /// Automatic deduction of an appropriate pass manager stack is not supported.
394 /// For example, to insert a loop pass 'lpass' into a FunctinoPassManager,
395 /// this is the valid pipeline text:
396 ///
397 /// function(lpass)
398 Error parsePassPipeline(CGSCCPassManager &CGPM, StringRef PipelineText,
399 bool VerifyEachPass = true,
400 bool DebugLogging = false);
401 Error parsePassPipeline(FunctionPassManager &FPM, StringRef PipelineText,
402 bool VerifyEachPass = true,
403 bool DebugLogging = false);
404 Error parsePassPipeline(LoopPassManager &LPM, StringRef PipelineText,
405 bool VerifyEachPass = true,
406 bool DebugLogging = false);
407 /// @}}
408
409 /// Parse a textual alias analysis pipeline into the provided AA manager.
410 ///
411 /// The format of the textual AA pipeline is a comma separated list of AA
412 /// pass names:
413 ///
414 /// basic-aa,globals-aa,...
415 ///
416 /// The AA manager is set up such that the provided alias analyses are tried
417 /// in the order specified. See the \c AAManaager documentation for details
418 /// about the logic used. This routine just provides the textual mapping
419 /// between AA names and the analyses to register with the manager.
420 ///
421 /// Returns false if the text cannot be parsed cleanly. The specific state of
422 /// the \p AA manager is unspecified if such an error is encountered and this
423 /// returns false.
424 Error parseAAPipeline(AAManager &AA, StringRef PipelineText);
425
426 /// Register a callback for a default optimizer pipeline extension
427 /// point
428 ///
429 /// This extension point allows adding passes that perform peephole
430 /// optimizations similar to the instruction combiner. These passes will be
431 /// inserted after each instance of the instruction combiner pass.
432 void registerPeepholeEPCallback(
433 const std::function<void(FunctionPassManager &, OptimizationLevel)> &C) {
434 PeepholeEPCallbacks.push_back(C);
435 }
436
437 /// Register a callback for a default optimizer pipeline extension
438 /// point
439 ///
440 /// This extension point allows adding late loop canonicalization and
441 /// simplification passes. This is the last point in the loop optimization
442 /// pipeline before loop deletion. Each pass added
443 /// here must be an instance of LoopPass.
444 /// This is the place to add passes that can remove loops, such as target-
445 /// specific loop idiom recognition.
446 void registerLateLoopOptimizationsEPCallback(
447 const std::function<void(LoopPassManager &, OptimizationLevel)> &C) {
448 LateLoopOptimizationsEPCallbacks.push_back(C);
449 }
450
451 /// Register a callback for a default optimizer pipeline extension
452 /// point
453 ///
454 /// This extension point allows adding loop passes to the end of the loop
455 /// optimizer.
456 void registerLoopOptimizerEndEPCallback(
457 const std::function<void(LoopPassManager &, OptimizationLevel)> &C) {
458 LoopOptimizerEndEPCallbacks.push_back(C);
459 }
460
461 /// Register a callback for a default optimizer pipeline extension
462 /// point
463 ///
464 /// This extension point allows adding optimization passes after most of the
465 /// main optimizations, but before the last cleanup-ish optimizations.
466 void registerScalarOptimizerLateEPCallback(
467 const std::function<void(FunctionPassManager &, OptimizationLevel)> &C) {
468 ScalarOptimizerLateEPCallbacks.push_back(C);
469 }
470
471 /// Register a callback for a default optimizer pipeline extension
472 /// point
473 ///
474 /// This extension point allows adding CallGraphSCC passes at the end of the
475 /// main CallGraphSCC passes and before any function simplification passes run
476 /// by CGPassManager.
477 void registerCGSCCOptimizerLateEPCallback(
478 const std::function<void(CGSCCPassManager &, OptimizationLevel)> &C) {
479 CGSCCOptimizerLateEPCallbacks.push_back(C);
480 }
481
482 /// Register a callback for a default optimizer pipeline extension
483 /// point
484 ///
485 /// This extension point allows adding optimization passes before the
486 /// vectorizer and other highly target specific optimization passes are
487 /// executed.
488 void registerVectorizerStartEPCallback(
489 const std::function<void(FunctionPassManager &, OptimizationLevel)> &C) {
490 VectorizerStartEPCallbacks.push_back(C);
491 }
492
493 /// Register a callback for a default optimizer pipeline extension point.
494 ///
495 /// This extension point allows adding optimization once at the start of the
496 /// pipeline. This does not apply to 'backend' compiles (LTO and ThinLTO
497 /// link-time pipelines).
498 void registerPipelineStartEPCallback(
499 const std::function<void(ModulePassManager &)> &C) {
500 PipelineStartEPCallbacks.push_back(C);
501 }
502
503 /// Register a callback for a default optimizer pipeline extension point
504 ///
505 /// This extension point allows adding optimizations at the very end of the
506 /// function optimization pipeline. A key difference between this and the
507 /// legacy PassManager's OptimizerLast callback is that this extension point
508 /// is not triggered at O0. Extensions to the O0 pipeline should append their
509 /// passes to the end of the overall pipeline.
510 void registerOptimizerLastEPCallback(
511 const std::function<void(FunctionPassManager &, OptimizationLevel)> &C) {
512 OptimizerLastEPCallbacks.push_back(C);
513 }
514
515 /// Register a callback for parsing an AliasAnalysis Name to populate
516 /// the given AAManager \p AA
517 void registerParseAACallback(
518 const std::function<bool(StringRef Name, AAManager &AA)> &C) {
519 AAParsingCallbacks.push_back(C);
520 }
521
522 /// {{@ Register callbacks for analysis registration with this PassBuilder
523 /// instance.
524 /// Callees register their analyses with the given AnalysisManager objects.
525 void registerAnalysisRegistrationCallback(
526 const std::function<void(CGSCCAnalysisManager &)> &C) {
527 CGSCCAnalysisRegistrationCallbacks.push_back(C);
528 }
529 void registerAnalysisRegistrationCallback(
530 const std::function<void(FunctionAnalysisManager &)> &C) {
531 FunctionAnalysisRegistrationCallbacks.push_back(C);
532 }
533 void registerAnalysisRegistrationCallback(
534 const std::function<void(LoopAnalysisManager &)> &C) {
535 LoopAnalysisRegistrationCallbacks.push_back(C);
536 }
537 void registerAnalysisRegistrationCallback(
538 const std::function<void(ModuleAnalysisManager &)> &C) {
539 ModuleAnalysisRegistrationCallbacks.push_back(C);
540 }
541 /// @}}
542
543 /// {{@ Register pipeline parsing callbacks with this pass builder instance.
544 /// Using these callbacks, callers can parse both a single pass name, as well
545 /// as entire sub-pipelines, and populate the PassManager instance
546 /// accordingly.
547 void registerPipelineParsingCallback(
548 const std::function<bool(StringRef Name, CGSCCPassManager &,
549 ArrayRef<PipelineElement>)> &C) {
550 CGSCCPipelineParsingCallbacks.push_back(C);
551 }
552 void registerPipelineParsingCallback(
553 const std::function<bool(StringRef Name, FunctionPassManager &,
554 ArrayRef<PipelineElement>)> &C) {
555 FunctionPipelineParsingCallbacks.push_back(C);
556 }
557 void registerPipelineParsingCallback(
558 const std::function<bool(StringRef Name, LoopPassManager &,
559 ArrayRef<PipelineElement>)> &C) {
560 LoopPipelineParsingCallbacks.push_back(C);
561 }
562 void registerPipelineParsingCallback(
563 const std::function<bool(StringRef Name, ModulePassManager &,
564 ArrayRef<PipelineElement>)> &C) {
565 ModulePipelineParsingCallbacks.push_back(C);
566 }
567 /// @}}
568
569 /// Register a callback for a top-level pipeline entry.
570 ///
571 /// If the PassManager type is not given at the top level of the pipeline
572 /// text, this Callback should be used to determine the appropriate stack of
573 /// PassManagers and populate the passed ModulePassManager.
574 void registerParseTopLevelPipelineCallback(
575 const std::function<bool(ModulePassManager &, ArrayRef<PipelineElement>,
576 bool VerifyEachPass, bool DebugLogging)> &C) {
577 TopLevelPipelineParsingCallbacks.push_back(C);
578 }
579
580private:
581 static Optional<std::vector<PipelineElement>>
582 parsePipelineText(StringRef Text);
583
584 Error parseModulePass(ModulePassManager &MPM, const PipelineElement &E,
585 bool VerifyEachPass, bool DebugLogging);
586 Error parseCGSCCPass(CGSCCPassManager &CGPM, const PipelineElement &E,
587 bool VerifyEachPass, bool DebugLogging);
588 Error parseFunctionPass(FunctionPassManager &FPM, const PipelineElement &E,
589 bool VerifyEachPass, bool DebugLogging);
590 Error parseLoopPass(LoopPassManager &LPM, const PipelineElement &E,
591 bool VerifyEachPass, bool DebugLogging);
592 bool parseAAPassName(AAManager &AA, StringRef Name);
593
594 Error parseLoopPassPipeline(LoopPassManager &LPM,
595 ArrayRef<PipelineElement> Pipeline,
596 bool VerifyEachPass, bool DebugLogging);
597 Error parseFunctionPassPipeline(FunctionPassManager &FPM,
598 ArrayRef<PipelineElement> Pipeline,
599 bool VerifyEachPass, bool DebugLogging);
600 Error parseCGSCCPassPipeline(CGSCCPassManager &CGPM,
601 ArrayRef<PipelineElement> Pipeline,
602 bool VerifyEachPass, bool DebugLogging);
603 Error parseModulePassPipeline(ModulePassManager &MPM,
604 ArrayRef<PipelineElement> Pipeline,
605 bool VerifyEachPass, bool DebugLogging);
606
607 void addPGOInstrPasses(ModulePassManager &MPM, bool DebugLogging,
608 OptimizationLevel Level, bool RunProfileGen,
609 std::string ProfileGenFile,
610 std::string ProfileUseFile,
611 std::string ProfileRemappingFile);
612
613 void invokePeepholeEPCallbacks(FunctionPassManager &, OptimizationLevel);
614
615 // Extension Point callbacks
616 SmallVector<std::function<void(FunctionPassManager &, OptimizationLevel)>, 2>
617 PeepholeEPCallbacks;
618 SmallVector<std::function<void(LoopPassManager &, OptimizationLevel)>, 2>
619 LateLoopOptimizationsEPCallbacks;
620 SmallVector<std::function<void(LoopPassManager &, OptimizationLevel)>, 2>
621 LoopOptimizerEndEPCallbacks;
622 SmallVector<std::function<void(FunctionPassManager &, OptimizationLevel)>, 2>
623 ScalarOptimizerLateEPCallbacks;
624 SmallVector<std::function<void(CGSCCPassManager &, OptimizationLevel)>, 2>
625 CGSCCOptimizerLateEPCallbacks;
626 SmallVector<std::function<void(FunctionPassManager &, OptimizationLevel)>, 2>
627 VectorizerStartEPCallbacks;
628 SmallVector<std::function<void(FunctionPassManager &, OptimizationLevel)>, 2>
629 OptimizerLastEPCallbacks;
630 // Module callbacks
631 SmallVector<std::function<void(ModulePassManager &)>, 2>
632 PipelineStartEPCallbacks;
633 SmallVector<std::function<void(ModuleAnalysisManager &)>, 2>
634 ModuleAnalysisRegistrationCallbacks;
635 SmallVector<std::function<bool(StringRef, ModulePassManager &,
636 ArrayRef<PipelineElement>)>,
637 2>
638 ModulePipelineParsingCallbacks;
639 SmallVector<std::function<bool(ModulePassManager &, ArrayRef<PipelineElement>,
640 bool VerifyEachPass, bool DebugLogging)>,
641 2>
642 TopLevelPipelineParsingCallbacks;
643 // CGSCC callbacks
644 SmallVector<std::function<void(CGSCCAnalysisManager &)>, 2>
645 CGSCCAnalysisRegistrationCallbacks;
646 SmallVector<std::function<bool(StringRef, CGSCCPassManager &,
647 ArrayRef<PipelineElement>)>,
648 2>
649 CGSCCPipelineParsingCallbacks;
650 // Function callbacks
651 SmallVector<std::function<void(FunctionAnalysisManager &)>, 2>
652 FunctionAnalysisRegistrationCallbacks;
653 SmallVector<std::function<bool(StringRef, FunctionPassManager &,
654 ArrayRef<PipelineElement>)>,
655 2>
656 FunctionPipelineParsingCallbacks;
657 // Loop callbacks
658 SmallVector<std::function<void(LoopAnalysisManager &)>, 2>
659 LoopAnalysisRegistrationCallbacks;
660 SmallVector<std::function<bool(StringRef, LoopPassManager &,
661 ArrayRef<PipelineElement>)>,
662 2>
663 LoopPipelineParsingCallbacks;
664 // AA callbacks
665 SmallVector<std::function<bool(StringRef Name, AAManager &AA)>, 2>
666 AAParsingCallbacks;
667};
668
669/// This utility template takes care of adding require<> and invalidate<>
670/// passes for an analysis to a given \c PassManager. It is intended to be used
671/// during parsing of a pass pipeline when parsing a single PipelineName.
672/// When registering a new function analysis FancyAnalysis with the pass
673/// pipeline name "fancy-analysis", a matching ParsePipelineCallback could look
674/// like this:
675///
676/// static bool parseFunctionPipeline(StringRef Name, FunctionPassManager &FPM,
677/// ArrayRef<PipelineElement> P) {
678/// if (parseAnalysisUtilityPasses<FancyAnalysis>("fancy-analysis", Name,
679/// FPM))
680/// return true;
681/// return false;
682/// }
683template <typename AnalysisT, typename IRUnitT, typename AnalysisManagerT,
684 typename... ExtraArgTs>
685bool parseAnalysisUtilityPasses(
686 StringRef AnalysisName, StringRef PipelineName,
687 PassManager<IRUnitT, AnalysisManagerT, ExtraArgTs...> &PM) {
688 if (!PipelineName.endswith(">"))
689 return false;
690 // See if this is an invalidate<> pass name
691 if (PipelineName.startswith("invalidate<")) {
692 PipelineName = PipelineName.substr(11, PipelineName.size() - 12);
693 if (PipelineName != AnalysisName)
694 return false;
695 PM.addPass(InvalidateAnalysisPass<AnalysisT>());
696 return true;
697 }
698
699 // See if this is a require<> pass name
700 if (PipelineName.startswith("require<")) {
701 PipelineName = PipelineName.substr(8, PipelineName.size() - 9);
702 if (PipelineName != AnalysisName)
703 return false;
704 PM.addPass(RequireAnalysisPass<AnalysisT, IRUnitT, AnalysisManagerT,
705 ExtraArgTs...>());
706 return true;
707 }
708
709 return false;
710}
711}
712
713#endif