LCOV - code coverage report
Current view: top level - include/llvm/LTO - Config.h (source / functions) Hit Total Coverage
Test: llvm-toolchain.info Lines: 12 12 100.0 %
Date: 2018-05-20 00:06:23 Functions: 7 8 87.5 %
Legend: Lines: hit not hit

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

Generated by: LCOV version 1.13