Andrew Scull | 5e1ddfa | 2018-08-14 10:06:54 +0100 | [diff] [blame^] | 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 | /// 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 | |
| 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 | |
| 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 | }; |
| 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). |
| 187 | // FIXME: This should not be required as diagnostic handler is not callback. |
| 188 | struct LTOLLVMContext : LLVMContext { |
| 189 | |
| 190 | LTOLLVMContext(const Config &C) : DiagHandler(C.DiagHandler) { |
| 191 | setDiscardValueNames(C.ShouldDiscardValueNames); |
| 192 | enableDebugTypeODRUniquing(); |
| 193 | setDiagnosticHandler( |
| 194 | llvm::make_unique<LTOLLVMDiagnosticHandler>(&DiagHandler), true); |
| 195 | } |
| 196 | DiagnosticHandlerFunction DiagHandler; |
| 197 | }; |
| 198 | |
| 199 | } |
| 200 | } |
| 201 | |
| 202 | #endif |