Home | History | Annotate | Download | only in LTO
      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   /// 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 
     84   /// 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 
     93   /// Statistics output file path.
     94   std::string StatsFile;
     95 
     96   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 
    185 struct 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.
    199 struct 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
    214