|
120
|
1 //===-Config.h - LLVM Link Time Optimizer Configuration -------------------===//
|
|
|
2 //
|
|
|
3 // The LLVM Compiler Infrastructure
|
|
|
4 //
|
|
|
5 // This file is distributed under the University of Illinois Open Source
|
|
|
6 // License. See LICENSE.TXT for details.
|
|
|
7 //
|
|
|
8 //===----------------------------------------------------------------------===//
|
|
|
9 //
|
|
|
10 // This file defines the lto::Config data structure, which allows clients to
|
|
|
11 // configure LTO.
|
|
|
12 //
|
|
|
13 //===----------------------------------------------------------------------===//
|
|
|
14
|
|
|
15 #ifndef LLVM_LTO_CONFIG_H
|
|
|
16 #define LLVM_LTO_CONFIG_H
|
|
|
17
|
|
|
18 #include "llvm/IR/DiagnosticInfo.h"
|
|
|
19 #include "llvm/Support/CodeGen.h"
|
|
121
|
20 #include "llvm/Target/TargetMachine.h"
|
|
120
|
21 #include "llvm/Target/TargetOptions.h"
|
|
|
22
|
|
|
23 #include <functional>
|
|
|
24
|
|
|
25 namespace llvm {
|
|
|
26
|
|
|
27 class Error;
|
|
|
28 class Module;
|
|
|
29 class ModuleSummaryIndex;
|
|
|
30 class raw_pwrite_stream;
|
|
|
31
|
|
|
32 namespace lto {
|
|
|
33
|
|
|
34 /// LTO configuration. A linker can configure LTO by setting fields in this data
|
|
|
35 /// structure and passing it to the lto::LTO constructor.
|
|
|
36 struct Config {
|
|
121
|
37 // Note: when adding fields here, consider whether they need to be added to
|
|
|
38 // computeCacheKey in LTO.cpp.
|
|
120
|
39 std::string CPU;
|
|
|
40 TargetOptions Options;
|
|
|
41 std::vector<std::string> MAttrs;
|
|
121
|
42 Optional<Reloc::Model> RelocModel = Reloc::PIC_;
|
|
|
43 Optional<CodeModel::Model> CodeModel = None;
|
|
120
|
44 CodeGenOpt::Level CGOptLevel = CodeGenOpt::Default;
|
|
121
|
45 TargetMachine::CodeGenFileType CGFileType = TargetMachine::CGFT_ObjectFile;
|
|
120
|
46 unsigned OptLevel = 2;
|
|
|
47 bool DisableVerify = false;
|
|
|
48
|
|
121
|
49 /// Use the new pass manager
|
|
|
50 bool UseNewPM = false;
|
|
|
51
|
|
120
|
52 /// Disable entirely the optimizer, including importing for ThinLTO
|
|
|
53 bool CodeGenOnly = false;
|
|
|
54
|
|
|
55 /// If this field is set, the set of passes run in the middle-end optimizer
|
|
|
56 /// will be the one specified by the string. Only works with the new pass
|
|
|
57 /// manager as the old one doesn't have this ability.
|
|
|
58 std::string OptPipeline;
|
|
|
59
|
|
|
60 // If this field is set, it has the same effect of specifying an AA pipeline
|
|
|
61 // identified by the string. Only works with the new pass manager, in
|
|
|
62 // conjunction OptPipeline.
|
|
|
63 std::string AAPipeline;
|
|
|
64
|
|
|
65 /// Setting this field will replace target triples in input files with this
|
|
|
66 /// triple.
|
|
|
67 std::string OverrideTriple;
|
|
|
68
|
|
|
69 /// Setting this field will replace unspecified target triples in input files
|
|
|
70 /// with this triple.
|
|
|
71 std::string DefaultTriple;
|
|
|
72
|
|
121
|
73 /// Sample PGO profile path.
|
|
|
74 std::string SampleProfile;
|
|
|
75
|
|
|
76 /// Optimization remarks file path.
|
|
|
77 std::string RemarksFilename = "";
|
|
|
78
|
|
|
79 /// Whether to emit optimization remarks with hotness informations.
|
|
|
80 bool RemarksWithHotness = false;
|
|
|
81
|
|
|
82 /// Whether to emit the pass manager debuggging informations.
|
|
|
83 bool DebugPassManager = false;
|
|
|
84
|
|
120
|
85 bool ShouldDiscardValueNames = true;
|
|
|
86 DiagnosticHandlerFunction DiagHandler;
|
|
|
87
|
|
|
88 /// If this field is set, LTO will write input file paths and symbol
|
|
|
89 /// resolutions here in llvm-lto2 command line flag format. This can be
|
|
|
90 /// used for testing and for running the LTO pipeline outside of the linker
|
|
|
91 /// with llvm-lto2.
|
|
|
92 std::unique_ptr<raw_ostream> ResolutionFile;
|
|
|
93
|
|
|
94 /// The following callbacks deal with tasks, which normally represent the
|
|
|
95 /// entire optimization and code generation pipeline for what will become a
|
|
|
96 /// single native object file. Each task has a unique identifier between 0 and
|
|
|
97 /// getMaxTasks()-1, which is supplied to the callback via the Task parameter.
|
|
|
98 /// A task represents the entire pipeline for ThinLTO and regular
|
|
|
99 /// (non-parallel) LTO, but a parallel code generation task will be split into
|
|
|
100 /// N tasks before code generation, where N is the parallelism level.
|
|
|
101 ///
|
|
|
102 /// LTO may decide to stop processing a task at any time, for example if the
|
|
|
103 /// module is empty or if a module hook (see below) returns false. For this
|
|
|
104 /// reason, the client should not expect to receive exactly getMaxTasks()
|
|
|
105 /// native object files.
|
|
|
106
|
|
|
107 /// A module hook may be used by a linker to perform actions during the LTO
|
|
|
108 /// pipeline. For example, a linker may use this function to implement
|
|
|
109 /// -save-temps. If this function returns false, any further processing for
|
|
|
110 /// that task is aborted.
|
|
|
111 ///
|
|
|
112 /// Module hooks must be thread safe with respect to the linker's internal
|
|
|
113 /// data structures. A module hook will never be called concurrently from
|
|
|
114 /// multiple threads with the same task ID, or the same module.
|
|
|
115 ///
|
|
|
116 /// Note that in out-of-process backend scenarios, none of the hooks will be
|
|
|
117 /// called for ThinLTO tasks.
|
|
|
118 typedef std::function<bool(unsigned Task, const Module &)> ModuleHookFn;
|
|
|
119
|
|
|
120 /// This module hook is called after linking (regular LTO) or loading
|
|
|
121 /// (ThinLTO) the module, before modifying it.
|
|
|
122 ModuleHookFn PreOptModuleHook;
|
|
|
123
|
|
|
124 /// This hook is called after promoting any internal functions
|
|
|
125 /// (ThinLTO-specific).
|
|
|
126 ModuleHookFn PostPromoteModuleHook;
|
|
|
127
|
|
|
128 /// This hook is called after internalizing the module.
|
|
|
129 ModuleHookFn PostInternalizeModuleHook;
|
|
|
130
|
|
|
131 /// This hook is called after importing from other modules (ThinLTO-specific).
|
|
|
132 ModuleHookFn PostImportModuleHook;
|
|
|
133
|
|
|
134 /// This module hook is called after optimization is complete.
|
|
|
135 ModuleHookFn PostOptModuleHook;
|
|
|
136
|
|
|
137 /// This module hook is called before code generation. It is similar to the
|
|
|
138 /// PostOptModuleHook, but for parallel code generation it is called after
|
|
|
139 /// splitting the module.
|
|
|
140 ModuleHookFn PreCodeGenModuleHook;
|
|
|
141
|
|
|
142 /// A combined index hook is called after all per-module indexes have been
|
|
|
143 /// combined (ThinLTO-specific). It can be used to implement -save-temps for
|
|
|
144 /// the combined index.
|
|
|
145 ///
|
|
|
146 /// If this function returns false, any further processing for ThinLTO tasks
|
|
|
147 /// is aborted.
|
|
|
148 ///
|
|
|
149 /// It is called regardless of whether the backend is in-process, although it
|
|
|
150 /// is not called from individual backend processes.
|
|
|
151 typedef std::function<bool(const ModuleSummaryIndex &Index)>
|
|
|
152 CombinedIndexHookFn;
|
|
|
153 CombinedIndexHookFn CombinedIndexHook;
|
|
|
154
|
|
|
155 /// This is a convenience function that configures this Config object to write
|
|
|
156 /// temporary files named after the given OutputFileName for each of the LTO
|
|
|
157 /// phases to disk. A client can use this function to implement -save-temps.
|
|
|
158 ///
|
|
|
159 /// FIXME: Temporary files derived from ThinLTO backends are currently named
|
|
|
160 /// after the input file name, rather than the output file name, when
|
|
|
161 /// UseInputModulePath is set to true.
|
|
|
162 ///
|
|
|
163 /// Specifically, it (1) sets each of the above module hooks and the combined
|
|
|
164 /// index hook to a function that calls the hook function (if any) that was
|
|
|
165 /// present in the appropriate field when the addSaveTemps function was
|
|
|
166 /// called, and writes the module to a bitcode file with a name prefixed by
|
|
|
167 /// the given output file name, and (2) creates a resolution file whose name
|
|
|
168 /// is prefixed by the given output file name and sets ResolutionFile to its
|
|
|
169 /// file handle.
|
|
|
170 Error addSaveTemps(std::string OutputFileName,
|
|
|
171 bool UseInputModulePath = false);
|
|
|
172 };
|
|
|
173
|
|
121
|
174 struct LTOLLVMDiagnosticHandler : public DiagnosticHandler {
|
|
|
175 DiagnosticHandlerFunction *Fn;
|
|
|
176 LTOLLVMDiagnosticHandler(DiagnosticHandlerFunction *DiagHandlerFn)
|
|
|
177 : Fn(DiagHandlerFn) {}
|
|
|
178 bool handleDiagnostics(const DiagnosticInfo &DI) override {
|
|
|
179 (*Fn)(DI);
|
|
|
180 return true;
|
|
|
181 }
|
|
|
182 };
|
|
120
|
183 /// A derived class of LLVMContext that initializes itself according to a given
|
|
|
184 /// Config object. The purpose of this class is to tie ownership of the
|
|
|
185 /// diagnostic handler to the context, as opposed to the Config object (which
|
|
|
186 /// may be ephemeral).
|
|
121
|
187 // FIXME: This should not be required as diagnostic handler is not callback.
|
|
120
|
188 struct LTOLLVMContext : LLVMContext {
|
|
|
189
|
|
|
190 LTOLLVMContext(const Config &C) : DiagHandler(C.DiagHandler) {
|
|
|
191 setDiscardValueNames(C.ShouldDiscardValueNames);
|
|
|
192 enableDebugTypeODRUniquing();
|
|
121
|
193 setDiagnosticHandler(
|
|
|
194 llvm::make_unique<LTOLLVMDiagnosticHandler>(&DiagHandler), true);
|
|
120
|
195 }
|
|
|
196 DiagnosticHandlerFunction DiagHandler;
|
|
|
197 };
|
|
|
198
|
|
|
199 }
|
|
|
200 }
|
|
|
201
|
|
|
202 #endif
|
