Line data Source code
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"
20 : #include "llvm/Target/TargetMachine.h"
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 {
37 : // Note: when adding fields here, consider whether they need to be added to
38 : // computeCacheKey in LTO.cpp.
39 : std::string CPU;
40 : TargetOptions Options;
41 : std::vector<std::string> MAttrs;
42 : Optional<Reloc::Model> RelocModel = Reloc::PIC_;
43 : Optional<CodeModel::Model> CodeModel = None;
44 : CodeGenOpt::Level CGOptLevel = CodeGenOpt::Default;
45 : TargetMachine::CodeGenFileType CGFileType = TargetMachine::CGFT_ObjectFile;
46 : unsigned OptLevel = 2;
47 : bool DisableVerify = false;
48 :
49 : /// Use the new pass manager
50 : bool UseNewPM = false;
51 :
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 :
73 : /// Sample PGO profile path.
74 : std::string SampleProfile;
75 :
76 : /// Name remapping file for profile data.
77 : std::string ProfileRemapping;
78 :
79 : /// The directory to store .dwo files.
80 : std::string DwoDir;
81 :
82 : /// The path to write a .dwo file to. This should generally only be used when
83 : /// running an individual backend directly via thinBackend(), as otherwise
84 : /// all .dwo files will be written to the same path.
85 : std::string DwoPath;
86 :
87 : /// Optimization remarks file path.
88 : std::string RemarksFilename = "";
89 :
90 : /// Whether to emit optimization remarks with hotness informations.
91 : bool RemarksWithHotness = false;
92 :
93 : /// Whether to emit the pass manager debuggging informations.
94 : bool DebugPassManager = false;
95 :
96 : /// Statistics output file path.
97 : std::string StatsFile;
98 :
99 : bool ShouldDiscardValueNames = true;
100 : DiagnosticHandlerFunction DiagHandler;
101 :
102 : /// If this field is set, LTO will write input file paths and symbol
103 : /// resolutions here in llvm-lto2 command line flag format. This can be
104 : /// used for testing and for running the LTO pipeline outside of the linker
105 : /// with llvm-lto2.
106 : std::unique_ptr<raw_ostream> ResolutionFile;
107 :
108 : /// The following callbacks deal with tasks, which normally represent the
109 : /// entire optimization and code generation pipeline for what will become a
110 : /// single native object file. Each task has a unique identifier between 0 and
111 : /// getMaxTasks()-1, which is supplied to the callback via the Task parameter.
112 : /// A task represents the entire pipeline for ThinLTO and regular
113 : /// (non-parallel) LTO, but a parallel code generation task will be split into
114 : /// N tasks before code generation, where N is the parallelism level.
115 : ///
116 : /// LTO may decide to stop processing a task at any time, for example if the
117 : /// module is empty or if a module hook (see below) returns false. For this
118 : /// reason, the client should not expect to receive exactly getMaxTasks()
119 : /// native object files.
120 :
121 : /// A module hook may be used by a linker to perform actions during the LTO
122 : /// pipeline. For example, a linker may use this function to implement
123 : /// -save-temps. If this function returns false, any further processing for
124 : /// that task is aborted.
125 : ///
126 : /// Module hooks must be thread safe with respect to the linker's internal
127 : /// data structures. A module hook will never be called concurrently from
128 : /// multiple threads with the same task ID, or the same module.
129 : ///
130 : /// Note that in out-of-process backend scenarios, none of the hooks will be
131 : /// called for ThinLTO tasks.
132 : typedef std::function<bool(unsigned Task, const Module &)> ModuleHookFn;
133 :
134 : /// This module hook is called after linking (regular LTO) or loading
135 : /// (ThinLTO) the module, before modifying it.
136 : ModuleHookFn PreOptModuleHook;
137 :
138 : /// This hook is called after promoting any internal functions
139 : /// (ThinLTO-specific).
140 : ModuleHookFn PostPromoteModuleHook;
141 :
142 : /// This hook is called after internalizing the module.
143 : ModuleHookFn PostInternalizeModuleHook;
144 :
145 : /// This hook is called after importing from other modules (ThinLTO-specific).
146 : ModuleHookFn PostImportModuleHook;
147 :
148 : /// This module hook is called after optimization is complete.
149 : ModuleHookFn PostOptModuleHook;
150 :
151 : /// This module hook is called before code generation. It is similar to the
152 : /// PostOptModuleHook, but for parallel code generation it is called after
153 : /// splitting the module.
154 : ModuleHookFn PreCodeGenModuleHook;
155 :
156 : /// A combined index hook is called after all per-module indexes have been
157 : /// combined (ThinLTO-specific). It can be used to implement -save-temps for
158 : /// the combined index.
159 : ///
160 : /// If this function returns false, any further processing for ThinLTO tasks
161 : /// is aborted.
162 : ///
163 : /// It is called regardless of whether the backend is in-process, although it
164 : /// is not called from individual backend processes.
165 : typedef std::function<bool(const ModuleSummaryIndex &Index)>
166 : CombinedIndexHookFn;
167 : CombinedIndexHookFn CombinedIndexHook;
168 :
169 : /// This is a convenience function that configures this Config object to write
170 : /// temporary files named after the given OutputFileName for each of the LTO
171 : /// phases to disk. A client can use this function to implement -save-temps.
172 : ///
173 : /// FIXME: Temporary files derived from ThinLTO backends are currently named
174 : /// after the input file name, rather than the output file name, when
175 : /// UseInputModulePath is set to true.
176 : ///
177 : /// Specifically, it (1) sets each of the above module hooks and the combined
178 : /// index hook to a function that calls the hook function (if any) that was
179 : /// present in the appropriate field when the addSaveTemps function was
180 : /// called, and writes the module to a bitcode file with a name prefixed by
181 : /// the given output file name, and (2) creates a resolution file whose name
182 : /// is prefixed by the given output file name and sets ResolutionFile to its
183 : /// file handle.
184 : Error addSaveTemps(std::string OutputFileName,
185 : bool UseInputModulePath = false);
186 : };
187 :
188 : struct LTOLLVMDiagnosticHandler : public DiagnosticHandler {
189 : DiagnosticHandlerFunction *Fn;
190 : LTOLLVMDiagnosticHandler(DiagnosticHandlerFunction *DiagHandlerFn)
191 1454 : : Fn(DiagHandlerFn) {}
192 10 : bool handleDiagnostics(const DiagnosticInfo &DI) override {
193 10 : (*Fn)(DI);
194 10 : return true;
195 : }
196 : };
197 : /// A derived class of LLVMContext that initializes itself according to a given
198 : /// Config object. The purpose of this class is to tie ownership of the
199 : /// diagnostic handler to the context, as opposed to the Config object (which
200 : /// may be ephemeral).
201 : // FIXME: This should not be required as diagnostic handler is not callback.
202 : struct LTOLLVMContext : LLVMContext {
203 :
204 727 : LTOLLVMContext(const Config &C) : DiagHandler(C.DiagHandler) {
205 727 : setDiscardValueNames(C.ShouldDiscardValueNames);
206 727 : enableDebugTypeODRUniquing();
207 727 : setDiagnosticHandler(
208 : llvm::make_unique<LTOLLVMDiagnosticHandler>(&DiagHandler), true);
209 727 : }
210 : DiagnosticHandlerFunction DiagHandler;
211 : };
212 :
213 : }
214 : }
215 :
216 : #endif
|
