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