1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-18 18:42:46 +02:00
llvm-mirror/tools/gold/gold-plugin.cpp

987 lines
34 KiB
C++
Raw Normal View History

//===-- gold-plugin.cpp - Plugin to gold for Link Time Optimization ------===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This is a gold plugin for LLVM. It provides an LLVM implementation of the
// interface described in http://gcc.gnu.org/wiki/whopr/driver .
//
//===----------------------------------------------------------------------===//
#include "llvm/ADT/Statistic.h"
#include "llvm/Bitcode/BitcodeReader.h"
#include "llvm/Bitcode/BitcodeWriter.h"
#include "llvm/CodeGen/CommandFlags.h"
#include "llvm/Config/config.h" // plugin-api.h requires HAVE_STDINT_H
#include "llvm/IR/Constants.h"
Use the DiagnosticHandler to print diagnostics when reading bitcode. The bitcode reading interface used std::error_code to report an error to the callers and it is the callers job to print diagnostics. This is not ideal for error handling or diagnostic reporting: * For error handling, all that the callers care about is 3 possibilities: * It worked * The bitcode file is corrupted/invalid. * The file is not bitcode at all. * For diagnostic, it is user friendly to include far more information about the invalid case so the user can find out what is wrong with the bitcode file. This comes up, for example, when a developer introduces a bug while extending the format. The compromise we had was to have a lot of error codes. With this patch we use the DiagnosticHandler to communicate with the human and std::error_code to communicate with the caller. This allows us to have far fewer error codes and adds the infrastructure to print better diagnostics. This is so because the diagnostics are printed when he issue is found. The code that detected the problem in alive in the stack and can pass down as much context as needed. As an example the patch updates test/Bitcode/invalid.ll. Using a DiagnosticHandler also moves the fatal/non-fatal error decision to the caller. A simple one like llvm-dis can just use fatal errors. The gold plugin needs a bit more complex treatment because of being passed non-bitcode files. An hypothetical interactive tool would make all bitcode errors non-fatal. llvm-svn: 225562
2015-01-10 01:07:30 +01:00
#include "llvm/IR/DiagnosticPrinter.h"
#include "llvm/LTO/Caching.h"
[ThinLTO/gold] Handle bitcode archives Summary: Several changes were required for ThinLTO links involving bitcode archive static libraries. With this patch clang/llvm bootstraps with ThinLTO and gold. The first is that the gold callbacks get_input_file and release_input_file can normally be used to get file information for each constituent bitcode file within an archive. However, these interfaces lock the underlying file and can't be for each archive constituent for ThinLTO backends where we get all the input files up front and don't release any until after the backend threads complete. However, it is sufficient to only get and release once per file, and then each consituent bitcode file can be accessed via get_view. This required saving some information to identify which file handle is the "leader" for each claimed file sharing the same file descriptor, and other information so that get_input_file isn't necessary later when processing the backends. Second, the module paths in the index need to distinguish between different constituent bitcode files within the same archive file, otherwise they will all end up with the same archive file path. Do this by appending the offset within the archive for the start of the bitcode file, returned by get_input_file when we claim each bitcode file, and saving that along with the file handle. Third, rather than have the function importer try to load a file based on the module path identifier (which now contains a suffix to distinguish different bitcode files within an archive), use a custom module loader. This is the same approach taken in libLTO, and I am using the support refactored into the new LTO.h header in r270509. The module loader parses the bitcode files out of the memory buffers returned from gold via the get_view callback and saved in a map. This also means that we call the function importer directly, rather than add it to the pass pipeline (which was in the plan to do already for other reasons). Reviewers: pcc, joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D20559 llvm-svn: 270814
2016-05-26 03:46:41 +02:00
#include "llvm/LTO/LTO.h"
#include "llvm/Object/Error.h"
#include "llvm/Support/CachePruning.h"
#include "llvm/Support/CommandLine.h"
#include "llvm/Support/FileSystem.h"
#include "llvm/Support/ManagedStatic.h"
#include "llvm/Support/MemoryBuffer.h"
#include "llvm/Support/Path.h"
#include "llvm/Support/TargetSelect.h"
#include "llvm/Support/raw_ostream.h"
#include <list>
#include <map>
#include <plugin-api.h>
#include <string>
#include <system_error>
#include <utility>
#include <vector>
// FIXME: remove this declaration when we stop maintaining Ubuntu Quantal and
// Precise and Debian Wheezy (binutils 2.23 is required)
#define LDPO_PIE 3
#define LDPT_GET_SYMBOLS_V3 28
using namespace llvm;
using namespace lto;
static ld_plugin_status discard_message(int level, const char *format, ...) {
// Die loudly. Recent versions of Gold pass ld_plugin_message as the first
// callback in the transfer vector. This should never be called.
abort();
}
static ld_plugin_release_input_file release_input_file = nullptr;
static ld_plugin_get_input_file get_input_file = nullptr;
static ld_plugin_message message = discard_message;
namespace {
struct claimed_file {
void *handle;
[ThinLTO/gold] Handle bitcode archives Summary: Several changes were required for ThinLTO links involving bitcode archive static libraries. With this patch clang/llvm bootstraps with ThinLTO and gold. The first is that the gold callbacks get_input_file and release_input_file can normally be used to get file information for each constituent bitcode file within an archive. However, these interfaces lock the underlying file and can't be for each archive constituent for ThinLTO backends where we get all the input files up front and don't release any until after the backend threads complete. However, it is sufficient to only get and release once per file, and then each consituent bitcode file can be accessed via get_view. This required saving some information to identify which file handle is the "leader" for each claimed file sharing the same file descriptor, and other information so that get_input_file isn't necessary later when processing the backends. Second, the module paths in the index need to distinguish between different constituent bitcode files within the same archive file, otherwise they will all end up with the same archive file path. Do this by appending the offset within the archive for the start of the bitcode file, returned by get_input_file when we claim each bitcode file, and saving that along with the file handle. Third, rather than have the function importer try to load a file based on the module path identifier (which now contains a suffix to distinguish different bitcode files within an archive), use a custom module loader. This is the same approach taken in libLTO, and I am using the support refactored into the new LTO.h header in r270509. The module loader parses the bitcode files out of the memory buffers returned from gold via the get_view callback and saved in a map. This also means that we call the function importer directly, rather than add it to the pass pipeline (which was in the plan to do already for other reasons). Reviewers: pcc, joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D20559 llvm-svn: 270814
2016-05-26 03:46:41 +02:00
void *leader_handle;
std::vector<ld_plugin_symbol> syms;
[ThinLTO/gold] Handle bitcode archives Summary: Several changes were required for ThinLTO links involving bitcode archive static libraries. With this patch clang/llvm bootstraps with ThinLTO and gold. The first is that the gold callbacks get_input_file and release_input_file can normally be used to get file information for each constituent bitcode file within an archive. However, these interfaces lock the underlying file and can't be for each archive constituent for ThinLTO backends where we get all the input files up front and don't release any until after the backend threads complete. However, it is sufficient to only get and release once per file, and then each consituent bitcode file can be accessed via get_view. This required saving some information to identify which file handle is the "leader" for each claimed file sharing the same file descriptor, and other information so that get_input_file isn't necessary later when processing the backends. Second, the module paths in the index need to distinguish between different constituent bitcode files within the same archive file, otherwise they will all end up with the same archive file path. Do this by appending the offset within the archive for the start of the bitcode file, returned by get_input_file when we claim each bitcode file, and saving that along with the file handle. Third, rather than have the function importer try to load a file based on the module path identifier (which now contains a suffix to distinguish different bitcode files within an archive), use a custom module loader. This is the same approach taken in libLTO, and I am using the support refactored into the new LTO.h header in r270509. The module loader parses the bitcode files out of the memory buffers returned from gold via the get_view callback and saved in a map. This also means that we call the function importer directly, rather than add it to the pass pipeline (which was in the plan to do already for other reasons). Reviewers: pcc, joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D20559 llvm-svn: 270814
2016-05-26 03:46:41 +02:00
off_t filesize;
std::string name;
};
/// RAII wrapper to manage opening and releasing of a ld_plugin_input_file.
struct PluginInputFile {
void *Handle;
std::unique_ptr<ld_plugin_input_file> File;
PluginInputFile(void *Handle) : Handle(Handle) {
File = llvm::make_unique<ld_plugin_input_file>();
if (get_input_file(Handle, File.get()) != LDPS_OK)
message(LDPL_FATAL, "Failed to get file information");
}
~PluginInputFile() {
// File would have been reset to nullptr if we moved this object
// to a new owner.
if (File)
if (release_input_file(Handle) != LDPS_OK)
message(LDPL_FATAL, "Failed to release file information");
}
ld_plugin_input_file &file() { return *File; }
PluginInputFile(PluginInputFile &&RHS) = default;
PluginInputFile &operator=(PluginInputFile &&RHS) = default;
};
struct ResolutionInfo {
bool CanOmitFromDynSym = true;
bool DefaultVisibility = true;
};
}
static ld_plugin_add_symbols add_symbols = nullptr;
static ld_plugin_get_symbols get_symbols = nullptr;
static ld_plugin_add_input_file add_input_file = nullptr;
static ld_plugin_set_extra_library_path set_extra_library_path = nullptr;
static ld_plugin_get_view get_view = nullptr;
static bool IsExecutable = false;
static Optional<Reloc::Model> RelocationModel = None;
static std::string output_name = "";
static std::list<claimed_file> Modules;
[ThinLTO/gold] Handle bitcode archives Summary: Several changes were required for ThinLTO links involving bitcode archive static libraries. With this patch clang/llvm bootstraps with ThinLTO and gold. The first is that the gold callbacks get_input_file and release_input_file can normally be used to get file information for each constituent bitcode file within an archive. However, these interfaces lock the underlying file and can't be for each archive constituent for ThinLTO backends where we get all the input files up front and don't release any until after the backend threads complete. However, it is sufficient to only get and release once per file, and then each consituent bitcode file can be accessed via get_view. This required saving some information to identify which file handle is the "leader" for each claimed file sharing the same file descriptor, and other information so that get_input_file isn't necessary later when processing the backends. Second, the module paths in the index need to distinguish between different constituent bitcode files within the same archive file, otherwise they will all end up with the same archive file path. Do this by appending the offset within the archive for the start of the bitcode file, returned by get_input_file when we claim each bitcode file, and saving that along with the file handle. Third, rather than have the function importer try to load a file based on the module path identifier (which now contains a suffix to distinguish different bitcode files within an archive), use a custom module loader. This is the same approach taken in libLTO, and I am using the support refactored into the new LTO.h header in r270509. The module loader parses the bitcode files out of the memory buffers returned from gold via the get_view callback and saved in a map. This also means that we call the function importer directly, rather than add it to the pass pipeline (which was in the plan to do already for other reasons). Reviewers: pcc, joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D20559 llvm-svn: 270814
2016-05-26 03:46:41 +02:00
static DenseMap<int, void *> FDToLeaderHandle;
static StringMap<ResolutionInfo> ResInfo;
static std::vector<std::string> Cleanup;
namespace options {
enum OutputType {
OT_NORMAL,
OT_DISABLE,
OT_BC_ONLY,
OT_SAVE_TEMPS
};
static OutputType TheOutputType = OT_NORMAL;
static unsigned OptLevel = 2;
// Default parallelism of 0 used to indicate that user did not specify.
// Actual parallelism default value depends on implementation.
// Currently only affects ThinLTO, where the default is
// llvm::heavyweight_hardware_concurrency.
static unsigned Parallelism = 0;
// Default regular LTO codegen parallelism (number of partitions).
static unsigned ParallelCodeGenParallelismLevel = 1;
#ifdef NDEBUG
static bool DisableVerify = true;
#else
static bool DisableVerify = false;
#endif
static std::string obj_path;
static std::string extra_library_path;
static std::string triple;
static std::string mcpu;
// When the thinlto plugin option is specified, only read the function
// the information from intermediate files and write a combined
// global index for the ThinLTO backends.
static bool thinlto = false;
// If false, all ThinLTO backend compilations through code gen are performed
// using multiple threads in the gold-plugin, before handing control back to
// gold. If true, write individual backend index files which reflect
// the import decisions, and exit afterwards. The assumption is
// that the build system will launch the backend processes.
static bool thinlto_index_only = false;
// If non-empty, holds the name of a file in which to write the list of
// oject files gold selected for inclusion in the link after symbol
// resolution (i.e. they had selected symbols). This will only be non-empty
// in the thinlto_index_only case. It is used to identify files, which may
// have originally been within archive libraries specified via
// --start-lib/--end-lib pairs, that should be included in the final
// native link process (since intervening function importing and inlining
// may change the symbol resolution detected in the final link and which
// files to include out of --start-lib/--end-lib libraries as a result).
static std::string thinlto_linked_objects_file;
// If true, when generating individual index files for distributed backends,
// also generate a "${bitcodefile}.imports" file at the same location for each
// bitcode file, listing the files it imports from in plain text. This is to
// support distributed build file staging.
static bool thinlto_emit_imports_files = false;
// Option to control where files for a distributed backend (the individual
// index files and optional imports files) are created.
// If specified, expects a string of the form "oldprefix:newprefix", and
// instead of generating these files in the same directory path as the
// corresponding bitcode file, will use a path formed by replacing the
// bitcode file's path prefix matching oldprefix with newprefix.
static std::string thinlto_prefix_replace;
[ThinLTO] Add support for emitting minimized bitcode for thin link Summary: The cumulative size of the bitcode files for a very large application can be huge, particularly with -g. In a distributed build environment, all of these files must be sent to the remote build node that performs the thin link step, and this can exceed size limits. The thin link actually only needs the summary along with a bitcode symbol table. Until we have a proper bitcode symbol table, simply stripping the debug metadata results in significant size reduction. Add support for an option to additionally emit minimized bitcode modules, just for use in the thin link step, which for now just strips all debug metadata. I plan to add a cc1 option so this can be invoked easily during the compile step. However, care must be taken to ensure that these minimized thin link bitcode files produce the same index as with the original bitcode files, as these original bitcode files will be used in the backends. Specifically: 1) The module hash used for caching is typically produced by hashing the written bitcode, and we want to include the hash that would correspond to the original bitcode file. This is because we want to ensure that changes in the stripped portions affect caching. Added plumbing to emit the same module hash in the minimized thin link bitcode file. 2) The module paths in the index are constructed from the module ID of each thin linked bitcode, and typically is automatically generated from the input file path. This is the path used for finding the modules to import from, and obviously we need this to point to the original bitcode files. Added gold-plugin support to take a suffix replacement during the thin link that is used to override the identifier on the MemoryBufferRef constructed from the loaded thin link bitcode file. The assumption is that the build system can specify that the minimized bitcode file has a name that is similar but uses a different suffix (e.g. out.thinlink.bc instead of out.o). Added various tests to ensure that we get identical index files out of the thin link step. Reviewers: mehdi_amini, pcc Subscribers: Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D31027 llvm-svn: 298638
2017-03-23 20:47:39 +01:00
// Option to control the name of modules encoded in the individual index
// files for a distributed backend. This enables the use of minimized
// bitcode files for the thin link, assuming the name of the full bitcode
// file used in the backend differs just in some part of the file suffix.
// If specified, expects a string of the form "oldsuffix:newsuffix".
static std::string thinlto_object_suffix_replace;
// Optional path to a directory for caching ThinLTO objects.
static std::string cache_dir;
// Optional pruning policy for ThinLTO caches.
static std::string cache_policy;
// Additional options to pass into the code generator.
2010-06-03 19:10:17 +02:00
// Note: This array will contain all plugin options which are not claimed
// as plugin exclusive to pass to the code generator.
static std::vector<const char *> extra;
// Sample profile file path
static std::string sample_profile;
static void process_plugin_option(const char *opt_)
{
if (opt_ == nullptr)
return;
llvm::StringRef opt = opt_;
if (opt.startswith("mcpu=")) {
mcpu = opt.substr(strlen("mcpu="));
} else if (opt.startswith("extra-library-path=")) {
extra_library_path = opt.substr(strlen("extra_library_path="));
2010-08-10 18:32:15 +02:00
} else if (opt.startswith("mtriple=")) {
triple = opt.substr(strlen("mtriple="));
} else if (opt.startswith("obj-path=")) {
obj_path = opt.substr(strlen("obj-path="));
} else if (opt == "emit-llvm") {
TheOutputType = OT_BC_ONLY;
} else if (opt == "save-temps") {
TheOutputType = OT_SAVE_TEMPS;
} else if (opt == "disable-output") {
TheOutputType = OT_DISABLE;
} else if (opt == "thinlto") {
thinlto = true;
} else if (opt == "thinlto-index-only") {
thinlto_index_only = true;
} else if (opt.startswith("thinlto-index-only=")) {
thinlto_index_only = true;
thinlto_linked_objects_file = opt.substr(strlen("thinlto-index-only="));
} else if (opt == "thinlto-emit-imports-files") {
thinlto_emit_imports_files = true;
} else if (opt.startswith("thinlto-prefix-replace=")) {
thinlto_prefix_replace = opt.substr(strlen("thinlto-prefix-replace="));
if (thinlto_prefix_replace.find(';') == std::string::npos)
message(LDPL_FATAL, "thinlto-prefix-replace expects 'old;new' format");
[ThinLTO] Add support for emitting minimized bitcode for thin link Summary: The cumulative size of the bitcode files for a very large application can be huge, particularly with -g. In a distributed build environment, all of these files must be sent to the remote build node that performs the thin link step, and this can exceed size limits. The thin link actually only needs the summary along with a bitcode symbol table. Until we have a proper bitcode symbol table, simply stripping the debug metadata results in significant size reduction. Add support for an option to additionally emit minimized bitcode modules, just for use in the thin link step, which for now just strips all debug metadata. I plan to add a cc1 option so this can be invoked easily during the compile step. However, care must be taken to ensure that these minimized thin link bitcode files produce the same index as with the original bitcode files, as these original bitcode files will be used in the backends. Specifically: 1) The module hash used for caching is typically produced by hashing the written bitcode, and we want to include the hash that would correspond to the original bitcode file. This is because we want to ensure that changes in the stripped portions affect caching. Added plumbing to emit the same module hash in the minimized thin link bitcode file. 2) The module paths in the index are constructed from the module ID of each thin linked bitcode, and typically is automatically generated from the input file path. This is the path used for finding the modules to import from, and obviously we need this to point to the original bitcode files. Added gold-plugin support to take a suffix replacement during the thin link that is used to override the identifier on the MemoryBufferRef constructed from the loaded thin link bitcode file. The assumption is that the build system can specify that the minimized bitcode file has a name that is similar but uses a different suffix (e.g. out.thinlink.bc instead of out.o). Added various tests to ensure that we get identical index files out of the thin link step. Reviewers: mehdi_amini, pcc Subscribers: Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D31027 llvm-svn: 298638
2017-03-23 20:47:39 +01:00
} else if (opt.startswith("thinlto-object-suffix-replace=")) {
thinlto_object_suffix_replace =
opt.substr(strlen("thinlto-object-suffix-replace="));
if (thinlto_object_suffix_replace.find(';') == std::string::npos)
message(LDPL_FATAL,
"thinlto-object-suffix-replace expects 'old;new' format");
} else if (opt.startswith("cache-dir=")) {
cache_dir = opt.substr(strlen("cache-dir="));
} else if (opt.startswith("cache-policy=")) {
cache_policy = opt.substr(strlen("cache-policy="));
} else if (opt.size() == 2 && opt[0] == 'O') {
if (opt[1] < '0' || opt[1] > '3')
message(LDPL_FATAL, "Optimization level must be between 0 and 3");
OptLevel = opt[1] - '0';
} else if (opt.startswith("jobs=")) {
if (StringRef(opt_ + 5).getAsInteger(10, Parallelism))
message(LDPL_FATAL, "Invalid parallelism level: %s", opt_ + 5);
} else if (opt.startswith("lto-partitions=")) {
if (opt.substr(strlen("lto-partitions="))
.getAsInteger(10, ParallelCodeGenParallelismLevel))
message(LDPL_FATAL, "Invalid codegen partition level: %s", opt_ + 5);
} else if (opt == "disable-verify") {
DisableVerify = true;
} else if (opt.startswith("sample-profile=")) {
sample_profile= opt.substr(strlen("sample-profile="));
} else {
// Save this option to pass to the code generator.
// ParseCommandLineOptions() expects argv[0] to be program name. Lazily
// add that.
if (extra.empty())
extra.push_back("LLVMgold");
extra.push_back(opt_);
}
}
}
static ld_plugin_status claim_file_hook(const ld_plugin_input_file *file,
int *claimed);
static ld_plugin_status all_symbols_read_hook(void);
static ld_plugin_status cleanup_hook(void);
extern "C" ld_plugin_status onload(ld_plugin_tv *tv);
ld_plugin_status onload(ld_plugin_tv *tv) {
InitializeAllTargetInfos();
InitializeAllTargets();
InitializeAllTargetMCs();
InitializeAllAsmParsers();
InitializeAllAsmPrinters();
// We're given a pointer to the first transfer vector. We read through them
// until we find one where tv_tag == LDPT_NULL. The REGISTER_* tagged values
// contain pointers to functions that we need to call to register our own
// hooks. The others are addresses of functions we can use to call into gold
// for services.
bool registeredClaimFile = false;
bool RegisteredAllSymbolsRead = false;
for (; tv->tv_tag != LDPT_NULL; ++tv) {
// Cast tv_tag to int to allow values not in "enum ld_plugin_tag", like, for
// example, LDPT_GET_SYMBOLS_V3 when building against an older plugin-api.h
// header.
switch (static_cast<int>(tv->tv_tag)) {
case LDPT_OUTPUT_NAME:
output_name = tv->tv_u.tv_string;
break;
case LDPT_LINKER_OUTPUT:
switch (tv->tv_u.tv_val) {
case LDPO_REL: // .o
IsExecutable = false;
break;
case LDPO_DYN: // .so
IsExecutable = false;
RelocationModel = Reloc::PIC_;
break;
case LDPO_PIE: // position independent executable
IsExecutable = true;
RelocationModel = Reloc::PIC_;
break;
case LDPO_EXEC: // .exe
IsExecutable = true;
RelocationModel = Reloc::Static;
break;
default:
message(LDPL_ERROR, "Unknown output file type %d", tv->tv_u.tv_val);
return LDPS_ERR;
}
break;
case LDPT_OPTION:
options::process_plugin_option(tv->tv_u.tv_string);
break;
case LDPT_REGISTER_CLAIM_FILE_HOOK: {
ld_plugin_register_claim_file callback;
callback = tv->tv_u.tv_register_claim_file;
if (callback(claim_file_hook) != LDPS_OK)
return LDPS_ERR;
registeredClaimFile = true;
} break;
case LDPT_REGISTER_ALL_SYMBOLS_READ_HOOK: {
ld_plugin_register_all_symbols_read callback;
callback = tv->tv_u.tv_register_all_symbols_read;
if (callback(all_symbols_read_hook) != LDPS_OK)
return LDPS_ERR;
RegisteredAllSymbolsRead = true;
} break;
case LDPT_REGISTER_CLEANUP_HOOK: {
ld_plugin_register_cleanup callback;
callback = tv->tv_u.tv_register_cleanup;
if (callback(cleanup_hook) != LDPS_OK)
return LDPS_ERR;
} break;
case LDPT_GET_INPUT_FILE:
get_input_file = tv->tv_u.tv_get_input_file;
break;
case LDPT_RELEASE_INPUT_FILE:
release_input_file = tv->tv_u.tv_release_input_file;
break;
case LDPT_ADD_SYMBOLS:
add_symbols = tv->tv_u.tv_add_symbols;
break;
case LDPT_GET_SYMBOLS_V2:
// Do not override get_symbols_v3 with get_symbols_v2.
if (!get_symbols)
get_symbols = tv->tv_u.tv_get_symbols;
break;
case LDPT_GET_SYMBOLS_V3:
get_symbols = tv->tv_u.tv_get_symbols;
break;
case LDPT_ADD_INPUT_FILE:
add_input_file = tv->tv_u.tv_add_input_file;
break;
case LDPT_SET_EXTRA_LIBRARY_PATH:
set_extra_library_path = tv->tv_u.tv_set_extra_library_path;
break;
case LDPT_GET_VIEW:
get_view = tv->tv_u.tv_get_view;
break;
case LDPT_MESSAGE:
message = tv->tv_u.tv_message;
break;
default:
break;
}
}
2009-02-18 09:30:15 +01:00
if (!registeredClaimFile) {
message(LDPL_ERROR, "register_claim_file not passed to LLVMgold.");
2009-02-18 18:49:06 +01:00
return LDPS_ERR;
}
2009-02-18 09:30:15 +01:00
if (!add_symbols) {
message(LDPL_ERROR, "add_symbols not passed to LLVMgold.");
2009-02-18 18:49:06 +01:00
return LDPS_ERR;
}
if (!RegisteredAllSymbolsRead)
return LDPS_OK;
if (!get_input_file) {
message(LDPL_ERROR, "get_input_file not passed to LLVMgold.");
return LDPS_ERR;
}
if (!release_input_file) {
message(LDPL_ERROR, "release_input_file not passed to LLVMgold.");
return LDPS_ERR;
}
return LDPS_OK;
}
static void diagnosticHandler(const DiagnosticInfo &DI) {
Use the DiagnosticHandler to print diagnostics when reading bitcode. The bitcode reading interface used std::error_code to report an error to the callers and it is the callers job to print diagnostics. This is not ideal for error handling or diagnostic reporting: * For error handling, all that the callers care about is 3 possibilities: * It worked * The bitcode file is corrupted/invalid. * The file is not bitcode at all. * For diagnostic, it is user friendly to include far more information about the invalid case so the user can find out what is wrong with the bitcode file. This comes up, for example, when a developer introduces a bug while extending the format. The compromise we had was to have a lot of error codes. With this patch we use the DiagnosticHandler to communicate with the human and std::error_code to communicate with the caller. This allows us to have far fewer error codes and adds the infrastructure to print better diagnostics. This is so because the diagnostics are printed when he issue is found. The code that detected the problem in alive in the stack and can pass down as much context as needed. As an example the patch updates test/Bitcode/invalid.ll. Using a DiagnosticHandler also moves the fatal/non-fatal error decision to the caller. A simple one like llvm-dis can just use fatal errors. The gold plugin needs a bit more complex treatment because of being passed non-bitcode files. An hypothetical interactive tool would make all bitcode errors non-fatal. llvm-svn: 225562
2015-01-10 01:07:30 +01:00
std::string ErrStorage;
{
raw_string_ostream OS(ErrStorage);
DiagnosticPrinterRawOStream DP(OS);
DI.print(DP);
}
ld_plugin_level Level;
switch (DI.getSeverity()) {
case DS_Error:
message(LDPL_FATAL, "LLVM gold plugin has failed to create LTO module: %s",
ErrStorage.c_str());
case DS_Warning:
Level = LDPL_WARNING;
break;
case DS_Note:
case DS_Remark:
Level = LDPL_INFO;
break;
}
message(Level, "LLVM gold plugin: %s", ErrStorage.c_str());
Use the DiagnosticHandler to print diagnostics when reading bitcode. The bitcode reading interface used std::error_code to report an error to the callers and it is the callers job to print diagnostics. This is not ideal for error handling or diagnostic reporting: * For error handling, all that the callers care about is 3 possibilities: * It worked * The bitcode file is corrupted/invalid. * The file is not bitcode at all. * For diagnostic, it is user friendly to include far more information about the invalid case so the user can find out what is wrong with the bitcode file. This comes up, for example, when a developer introduces a bug while extending the format. The compromise we had was to have a lot of error codes. With this patch we use the DiagnosticHandler to communicate with the human and std::error_code to communicate with the caller. This allows us to have far fewer error codes and adds the infrastructure to print better diagnostics. This is so because the diagnostics are printed when he issue is found. The code that detected the problem in alive in the stack and can pass down as much context as needed. As an example the patch updates test/Bitcode/invalid.ll. Using a DiagnosticHandler also moves the fatal/non-fatal error decision to the caller. A simple one like llvm-dis can just use fatal errors. The gold plugin needs a bit more complex treatment because of being passed non-bitcode files. An hypothetical interactive tool would make all bitcode errors non-fatal. llvm-svn: 225562
2015-01-10 01:07:30 +01:00
}
static void check(Error E, std::string Msg = "LLVM gold plugin") {
handleAllErrors(std::move(E), [&](ErrorInfoBase &EIB) -> Error {
message(LDPL_FATAL, "%s: %s", Msg.c_str(), EIB.message().c_str());
return Error::success();
});
}
template <typename T> static T check(Expected<T> E) {
if (E)
return std::move(*E);
check(E.takeError());
return T();
}
/// Called by gold to see whether this file is one that our plugin can handle.
/// We'll try to open it and register all the symbols with add_symbol if
/// possible.
static ld_plugin_status claim_file_hook(const ld_plugin_input_file *file,
int *claimed) {
MemoryBufferRef BufferRef;
std::unique_ptr<MemoryBuffer> Buffer;
if (get_view) {
const void *view;
if (get_view(file->handle, &view) != LDPS_OK) {
message(LDPL_ERROR, "Failed to get a view of %s", file->name);
return LDPS_ERR;
}
BufferRef =
MemoryBufferRef(StringRef((const char *)view, file->filesize), "");
} else {
int64_t offset = 0;
// Gold has found what might be IR part-way inside of a file, such as
// an .a archive.
if (file->offset) {
offset = file->offset;
}
ErrorOr<std::unique_ptr<MemoryBuffer>> BufferOrErr =
MemoryBuffer::getOpenFileSlice(file->fd, file->name, file->filesize,
offset);
if (std::error_code EC = BufferOrErr.getError()) {
message(LDPL_ERROR, EC.message().c_str());
return LDPS_ERR;
}
Buffer = std::move(BufferOrErr.get());
BufferRef = Buffer->getMemBufferRef();
}
*claimed = 1;
Expected<std::unique_ptr<InputFile>> ObjOrErr = InputFile::create(BufferRef);
if (!ObjOrErr) {
handleAllErrors(ObjOrErr.takeError(), [&](const ErrorInfoBase &EI) {
std::error_code EC = EI.convertToErrorCode();
if (EC == object::object_error::invalid_file_type ||
EC == object::object_error::bitcode_section_not_found)
*claimed = 0;
else
message(LDPL_FATAL,
"LLVM gold plugin has failed to create LTO module: %s",
EI.message().c_str());
});
return *claimed ? LDPS_ERR : LDPS_OK;
}
std::unique_ptr<InputFile> Obj = std::move(*ObjOrErr);
Modules.emplace_back();
claimed_file &cf = Modules.back();
cf.handle = file->handle;
[ThinLTO/gold] Handle bitcode archives Summary: Several changes were required for ThinLTO links involving bitcode archive static libraries. With this patch clang/llvm bootstraps with ThinLTO and gold. The first is that the gold callbacks get_input_file and release_input_file can normally be used to get file information for each constituent bitcode file within an archive. However, these interfaces lock the underlying file and can't be for each archive constituent for ThinLTO backends where we get all the input files up front and don't release any until after the backend threads complete. However, it is sufficient to only get and release once per file, and then each consituent bitcode file can be accessed via get_view. This required saving some information to identify which file handle is the "leader" for each claimed file sharing the same file descriptor, and other information so that get_input_file isn't necessary later when processing the backends. Second, the module paths in the index need to distinguish between different constituent bitcode files within the same archive file, otherwise they will all end up with the same archive file path. Do this by appending the offset within the archive for the start of the bitcode file, returned by get_input_file when we claim each bitcode file, and saving that along with the file handle. Third, rather than have the function importer try to load a file based on the module path identifier (which now contains a suffix to distinguish different bitcode files within an archive), use a custom module loader. This is the same approach taken in libLTO, and I am using the support refactored into the new LTO.h header in r270509. The module loader parses the bitcode files out of the memory buffers returned from gold via the get_view callback and saved in a map. This also means that we call the function importer directly, rather than add it to the pass pipeline (which was in the plan to do already for other reasons). Reviewers: pcc, joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D20559 llvm-svn: 270814
2016-05-26 03:46:41 +02:00
// Keep track of the first handle for each file descriptor, since there are
// multiple in the case of an archive. This is used later in the case of
// ThinLTO parallel backends to ensure that each file is only opened and
// released once.
auto LeaderHandle =
FDToLeaderHandle.insert(std::make_pair(file->fd, file->handle)).first;
cf.leader_handle = LeaderHandle->second;
// Save the filesize since for parallel ThinLTO backends we can only
// invoke get_input_file once per archive (only for the leader handle).
cf.filesize = file->filesize;
// In the case of an archive library, all but the first member must have a
// non-zero offset, which we can append to the file name to obtain a
// unique name.
cf.name = file->name;
if (file->offset)
cf.name += ".llvm." + std::to_string(file->offset) + "." +
sys::path::filename(Obj->getSourceFileName()).str();
for (auto &Sym : Obj->symbols()) {
cf.syms.push_back(ld_plugin_symbol());
ld_plugin_symbol &sym = cf.syms.back();
sym.version = nullptr;
StringRef Name = Sym.getName();
sym.name = strdup(Name.str().c_str());
ResolutionInfo &Res = ResInfo[Name];
Res.CanOmitFromDynSym &= Sym.canBeOmittedFromSymbolTable();
sym.visibility = LDPV_DEFAULT;
GlobalValue::VisibilityTypes Vis = Sym.getVisibility();
if (Vis != GlobalValue::DefaultVisibility)
Res.DefaultVisibility = false;
switch (Vis) {
case GlobalValue::DefaultVisibility:
break;
case GlobalValue::HiddenVisibility:
sym.visibility = LDPV_HIDDEN;
break;
case GlobalValue::ProtectedVisibility:
sym.visibility = LDPV_PROTECTED;
break;
}
if (Sym.isUndefined()) {
sym.def = LDPK_UNDEF;
if (Sym.isWeak())
sym.def = LDPK_WEAKUNDEF;
} else if (Sym.isCommon())
sym.def = LDPK_COMMON;
else if (Sym.isWeak())
sym.def = LDPK_WEAKDEF;
else
sym.def = LDPK_DEF;
sym.size = 0;
sym.comdat_key = nullptr;
int CI = Sym.getComdatIndex();
if (CI != -1) {
StringRef C = Obj->getComdatTable()[CI];
sym.comdat_key = strdup(C.str().c_str());
}
sym.resolution = LDPR_UNKNOWN;
}
if (!cf.syms.empty()) {
if (add_symbols(cf.handle, cf.syms.size(), cf.syms.data()) != LDPS_OK) {
message(LDPL_ERROR, "Unable to add symbols!");
return LDPS_ERR;
}
}
return LDPS_OK;
}
static void freeSymName(ld_plugin_symbol &Sym) {
free(Sym.name);
free(Sym.comdat_key);
Sym.name = nullptr;
Sym.comdat_key = nullptr;
}
/// Helper to get a file's symbols and a view into it via gold callbacks.
static const void *getSymbolsAndView(claimed_file &F) {
ld_plugin_status status = get_symbols(F.handle, F.syms.size(), F.syms.data());
if (status == LDPS_NO_SYMS)
return nullptr;
if (status != LDPS_OK)
message(LDPL_FATAL, "Failed to get symbol information");
const void *View;
if (get_view(F.handle, &View) != LDPS_OK)
message(LDPL_FATAL, "Failed to get a view of file");
return View;
}
[ThinLTO] Add support for emitting minimized bitcode for thin link Summary: The cumulative size of the bitcode files for a very large application can be huge, particularly with -g. In a distributed build environment, all of these files must be sent to the remote build node that performs the thin link step, and this can exceed size limits. The thin link actually only needs the summary along with a bitcode symbol table. Until we have a proper bitcode symbol table, simply stripping the debug metadata results in significant size reduction. Add support for an option to additionally emit minimized bitcode modules, just for use in the thin link step, which for now just strips all debug metadata. I plan to add a cc1 option so this can be invoked easily during the compile step. However, care must be taken to ensure that these minimized thin link bitcode files produce the same index as with the original bitcode files, as these original bitcode files will be used in the backends. Specifically: 1) The module hash used for caching is typically produced by hashing the written bitcode, and we want to include the hash that would correspond to the original bitcode file. This is because we want to ensure that changes in the stripped portions affect caching. Added plumbing to emit the same module hash in the minimized thin link bitcode file. 2) The module paths in the index are constructed from the module ID of each thin linked bitcode, and typically is automatically generated from the input file path. This is the path used for finding the modules to import from, and obviously we need this to point to the original bitcode files. Added gold-plugin support to take a suffix replacement during the thin link that is used to override the identifier on the MemoryBufferRef constructed from the loaded thin link bitcode file. The assumption is that the build system can specify that the minimized bitcode file has a name that is similar but uses a different suffix (e.g. out.thinlink.bc instead of out.o). Added various tests to ensure that we get identical index files out of the thin link step. Reviewers: mehdi_amini, pcc Subscribers: Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D31027 llvm-svn: 298638
2017-03-23 20:47:39 +01:00
/// Parse the thinlto-object-suffix-replace option into the \p OldSuffix and
/// \p NewSuffix strings, if it was specified.
static void getThinLTOOldAndNewSuffix(std::string &OldSuffix,
std::string &NewSuffix) {
assert(options::thinlto_object_suffix_replace.empty() ||
options::thinlto_object_suffix_replace.find(";") != StringRef::npos);
StringRef SuffixReplace = options::thinlto_object_suffix_replace;
std::tie(OldSuffix, NewSuffix) = SuffixReplace.split(';');
[ThinLTO] Add support for emitting minimized bitcode for thin link Summary: The cumulative size of the bitcode files for a very large application can be huge, particularly with -g. In a distributed build environment, all of these files must be sent to the remote build node that performs the thin link step, and this can exceed size limits. The thin link actually only needs the summary along with a bitcode symbol table. Until we have a proper bitcode symbol table, simply stripping the debug metadata results in significant size reduction. Add support for an option to additionally emit minimized bitcode modules, just for use in the thin link step, which for now just strips all debug metadata. I plan to add a cc1 option so this can be invoked easily during the compile step. However, care must be taken to ensure that these minimized thin link bitcode files produce the same index as with the original bitcode files, as these original bitcode files will be used in the backends. Specifically: 1) The module hash used for caching is typically produced by hashing the written bitcode, and we want to include the hash that would correspond to the original bitcode file. This is because we want to ensure that changes in the stripped portions affect caching. Added plumbing to emit the same module hash in the minimized thin link bitcode file. 2) The module paths in the index are constructed from the module ID of each thin linked bitcode, and typically is automatically generated from the input file path. This is the path used for finding the modules to import from, and obviously we need this to point to the original bitcode files. Added gold-plugin support to take a suffix replacement during the thin link that is used to override the identifier on the MemoryBufferRef constructed from the loaded thin link bitcode file. The assumption is that the build system can specify that the minimized bitcode file has a name that is similar but uses a different suffix (e.g. out.thinlink.bc instead of out.o). Added various tests to ensure that we get identical index files out of the thin link step. Reviewers: mehdi_amini, pcc Subscribers: Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D31027 llvm-svn: 298638
2017-03-23 20:47:39 +01:00
}
/// Given the original \p Path to an output file, replace any filename
/// suffix matching \p OldSuffix with \p NewSuffix.
static std::string getThinLTOObjectFileName(StringRef Path, StringRef OldSuffix,
StringRef NewSuffix) {
[ThinLTO] Add support for emitting minimized bitcode for thin link Summary: The cumulative size of the bitcode files for a very large application can be huge, particularly with -g. In a distributed build environment, all of these files must be sent to the remote build node that performs the thin link step, and this can exceed size limits. The thin link actually only needs the summary along with a bitcode symbol table. Until we have a proper bitcode symbol table, simply stripping the debug metadata results in significant size reduction. Add support for an option to additionally emit minimized bitcode modules, just for use in the thin link step, which for now just strips all debug metadata. I plan to add a cc1 option so this can be invoked easily during the compile step. However, care must be taken to ensure that these minimized thin link bitcode files produce the same index as with the original bitcode files, as these original bitcode files will be used in the backends. Specifically: 1) The module hash used for caching is typically produced by hashing the written bitcode, and we want to include the hash that would correspond to the original bitcode file. This is because we want to ensure that changes in the stripped portions affect caching. Added plumbing to emit the same module hash in the minimized thin link bitcode file. 2) The module paths in the index are constructed from the module ID of each thin linked bitcode, and typically is automatically generated from the input file path. This is the path used for finding the modules to import from, and obviously we need this to point to the original bitcode files. Added gold-plugin support to take a suffix replacement during the thin link that is used to override the identifier on the MemoryBufferRef constructed from the loaded thin link bitcode file. The assumption is that the build system can specify that the minimized bitcode file has a name that is similar but uses a different suffix (e.g. out.thinlink.bc instead of out.o). Added various tests to ensure that we get identical index files out of the thin link step. Reviewers: mehdi_amini, pcc Subscribers: Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D31027 llvm-svn: 298638
2017-03-23 20:47:39 +01:00
if (OldSuffix.empty() && NewSuffix.empty())
return Path;
StringRef NewPath = Path;
NewPath.consume_back(OldSuffix);
std::string NewNewPath = NewPath;
NewNewPath += NewSuffix;
return NewNewPath;
[ThinLTO] Add support for emitting minimized bitcode for thin link Summary: The cumulative size of the bitcode files for a very large application can be huge, particularly with -g. In a distributed build environment, all of these files must be sent to the remote build node that performs the thin link step, and this can exceed size limits. The thin link actually only needs the summary along with a bitcode symbol table. Until we have a proper bitcode symbol table, simply stripping the debug metadata results in significant size reduction. Add support for an option to additionally emit minimized bitcode modules, just for use in the thin link step, which for now just strips all debug metadata. I plan to add a cc1 option so this can be invoked easily during the compile step. However, care must be taken to ensure that these minimized thin link bitcode files produce the same index as with the original bitcode files, as these original bitcode files will be used in the backends. Specifically: 1) The module hash used for caching is typically produced by hashing the written bitcode, and we want to include the hash that would correspond to the original bitcode file. This is because we want to ensure that changes in the stripped portions affect caching. Added plumbing to emit the same module hash in the minimized thin link bitcode file. 2) The module paths in the index are constructed from the module ID of each thin linked bitcode, and typically is automatically generated from the input file path. This is the path used for finding the modules to import from, and obviously we need this to point to the original bitcode files. Added gold-plugin support to take a suffix replacement during the thin link that is used to override the identifier on the MemoryBufferRef constructed from the loaded thin link bitcode file. The assumption is that the build system can specify that the minimized bitcode file has a name that is similar but uses a different suffix (e.g. out.thinlink.bc instead of out.o). Added various tests to ensure that we get identical index files out of the thin link step. Reviewers: mehdi_amini, pcc Subscribers: Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D31027 llvm-svn: 298638
2017-03-23 20:47:39 +01:00
}
static bool isAlpha(char C) {
return ('a' <= C && C <= 'z') || ('A' <= C && C <= 'Z') || C == '_';
}
static bool isAlnum(char C) { return isAlpha(C) || ('0' <= C && C <= '9'); }
// Returns true if S is valid as a C language identifier.
static bool isValidCIdentifier(StringRef S) {
return !S.empty() && isAlpha(S[0]) &&
std::all_of(S.begin() + 1, S.end(), isAlnum);
}
[ThinLTO] Add support for emitting minimized bitcode for thin link Summary: The cumulative size of the bitcode files for a very large application can be huge, particularly with -g. In a distributed build environment, all of these files must be sent to the remote build node that performs the thin link step, and this can exceed size limits. The thin link actually only needs the summary along with a bitcode symbol table. Until we have a proper bitcode symbol table, simply stripping the debug metadata results in significant size reduction. Add support for an option to additionally emit minimized bitcode modules, just for use in the thin link step, which for now just strips all debug metadata. I plan to add a cc1 option so this can be invoked easily during the compile step. However, care must be taken to ensure that these minimized thin link bitcode files produce the same index as with the original bitcode files, as these original bitcode files will be used in the backends. Specifically: 1) The module hash used for caching is typically produced by hashing the written bitcode, and we want to include the hash that would correspond to the original bitcode file. This is because we want to ensure that changes in the stripped portions affect caching. Added plumbing to emit the same module hash in the minimized thin link bitcode file. 2) The module paths in the index are constructed from the module ID of each thin linked bitcode, and typically is automatically generated from the input file path. This is the path used for finding the modules to import from, and obviously we need this to point to the original bitcode files. Added gold-plugin support to take a suffix replacement during the thin link that is used to override the identifier on the MemoryBufferRef constructed from the loaded thin link bitcode file. The assumption is that the build system can specify that the minimized bitcode file has a name that is similar but uses a different suffix (e.g. out.thinlink.bc instead of out.o). Added various tests to ensure that we get identical index files out of the thin link step. Reviewers: mehdi_amini, pcc Subscribers: Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D31027 llvm-svn: 298638
2017-03-23 20:47:39 +01:00
static void addModule(LTO &Lto, claimed_file &F, const void *View,
StringRef Filename) {
MemoryBufferRef BufferRef(StringRef((const char *)View, F.filesize),
Filename);
Expected<std::unique_ptr<InputFile>> ObjOrErr = InputFile::create(BufferRef);
if (!ObjOrErr)
message(LDPL_FATAL, "Could not read bitcode from file : %s",
toString(ObjOrErr.takeError()).c_str());
unsigned SymNum = 0;
std::unique_ptr<InputFile> Input = std::move(ObjOrErr.get());
auto InputFileSyms = Input->symbols();
assert(InputFileSyms.size() == F.syms.size());
std::vector<SymbolResolution> Resols(F.syms.size());
for (ld_plugin_symbol &Sym : F.syms) {
const InputFile::Symbol &InpSym = InputFileSyms[SymNum];
SymbolResolution &R = Resols[SymNum++];
ld_plugin_symbol_resolution Resolution =
(ld_plugin_symbol_resolution)Sym.resolution;
ResolutionInfo &Res = ResInfo[Sym.name];
switch (Resolution) {
case LDPR_UNKNOWN:
llvm_unreachable("Unexpected resolution");
case LDPR_RESOLVED_IR:
case LDPR_RESOLVED_EXEC:
case LDPR_RESOLVED_DYN:
case LDPR_PREEMPTED_IR:
case LDPR_PREEMPTED_REG:
case LDPR_UNDEF:
break;
case LDPR_PREVAILING_DEF_IRONLY:
R.Prevailing = true;
break;
case LDPR_PREVAILING_DEF:
R.Prevailing = true;
R.VisibleToRegularObj = true;
break;
case LDPR_PREVAILING_DEF_IRONLY_EXP:
R.Prevailing = true;
if (!Res.CanOmitFromDynSym)
R.VisibleToRegularObj = true;
break;
}
// If the symbol has a C identifier section name, we need to mark
// it as visible to a regular object so that LTO will keep it around
// to ensure the linker generates special __start_<secname> and
// __stop_<secname> symbols which may be used elsewhere.
if (isValidCIdentifier(InpSym.getSectionName()))
R.VisibleToRegularObj = true;
if (Resolution != LDPR_RESOLVED_DYN && Resolution != LDPR_UNDEF &&
(IsExecutable || !Res.DefaultVisibility))
R.FinalDefinitionInLinkageUnit = true;
freeSymName(Sym);
}
check(Lto.add(std::move(Input), Resols),
std::string("Failed to link module ") + F.name);
}
static void recordFile(const std::string &Filename, bool TempOutFile) {
if (add_input_file(Filename.c_str()) != LDPS_OK)
message(LDPL_FATAL,
"Unable to add .o file to the link. File left behind in: %s",
Filename.c_str());
if (TempOutFile)
Cleanup.push_back(Filename);
}
/// Return the desired output filename given a base input name, a flag
/// indicating whether a temp file should be generated, and an optional task id.
/// The new filename generated is returned in \p NewFilename.
static int getOutputFileName(StringRef InFilename, bool TempOutFile,
SmallString<128> &NewFilename, int TaskID) {
int FD = -1;
if (TempOutFile) {
std::error_code EC =
sys::fs::createTemporaryFile("lto-llvm", "o", FD, NewFilename);
if (EC)
message(LDPL_FATAL, "Could not create temporary file: %s",
EC.message().c_str());
} else {
NewFilename = InFilename;
if (TaskID > 0)
NewFilename += utostr(TaskID);
std::error_code EC =
sys::fs::openFileForWrite(NewFilename, FD, sys::fs::F_None);
if (EC)
message(LDPL_FATAL, "Could not open file %s: %s", NewFilename.c_str(),
EC.message().c_str());
}
return FD;
}
static CodeGenOpt::Level getCGOptLevel() {
switch (options::OptLevel) {
case 0:
return CodeGenOpt::None;
case 1:
return CodeGenOpt::Less;
case 2:
return CodeGenOpt::Default;
case 3:
return CodeGenOpt::Aggressive;
}
llvm_unreachable("Invalid optimization level");
}
/// Parse the thinlto_prefix_replace option into the \p OldPrefix and
/// \p NewPrefix strings, if it was specified.
static void getThinLTOOldAndNewPrefix(std::string &OldPrefix,
std::string &NewPrefix) {
StringRef PrefixReplace = options::thinlto_prefix_replace;
assert(PrefixReplace.empty() || PrefixReplace.find(";") != StringRef::npos);
std::tie(OldPrefix, NewPrefix) = PrefixReplace.split(';');
}
static std::unique_ptr<LTO> createLTO() {
Config Conf;
ThinBackend Backend;
Conf.CPU = options::mcpu;
Conf.Options = InitTargetOptionsFromCodeGenFlags();
[ThinLTO/gold] Handle bitcode archives Summary: Several changes were required for ThinLTO links involving bitcode archive static libraries. With this patch clang/llvm bootstraps with ThinLTO and gold. The first is that the gold callbacks get_input_file and release_input_file can normally be used to get file information for each constituent bitcode file within an archive. However, these interfaces lock the underlying file and can't be for each archive constituent for ThinLTO backends where we get all the input files up front and don't release any until after the backend threads complete. However, it is sufficient to only get and release once per file, and then each consituent bitcode file can be accessed via get_view. This required saving some information to identify which file handle is the "leader" for each claimed file sharing the same file descriptor, and other information so that get_input_file isn't necessary later when processing the backends. Second, the module paths in the index need to distinguish between different constituent bitcode files within the same archive file, otherwise they will all end up with the same archive file path. Do this by appending the offset within the archive for the start of the bitcode file, returned by get_input_file when we claim each bitcode file, and saving that along with the file handle. Third, rather than have the function importer try to load a file based on the module path identifier (which now contains a suffix to distinguish different bitcode files within an archive), use a custom module loader. This is the same approach taken in libLTO, and I am using the support refactored into the new LTO.h header in r270509. The module loader parses the bitcode files out of the memory buffers returned from gold via the get_view callback and saved in a map. This also means that we call the function importer directly, rather than add it to the pass pipeline (which was in the plan to do already for other reasons). Reviewers: pcc, joker.eph Subscribers: llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D20559 llvm-svn: 270814
2016-05-26 03:46:41 +02:00
// Disable the new X86 relax relocations since gold might not support them.
// FIXME: Check the gold version or add a new option to enable them.
Conf.Options.RelaxELFRelocations = false;
// Enable function/data sections by default.
Conf.Options.FunctionSections = true;
Conf.Options.DataSections = true;
Conf.MAttrs = MAttrs;
Conf.RelocModel = RelocationModel;
Conf.CGOptLevel = getCGOptLevel();
Conf.DisableVerify = options::DisableVerify;
Conf.OptLevel = options::OptLevel;
if (options::Parallelism)
Backend = createInProcessThinBackend(options::Parallelism);
if (options::thinlto_index_only) {
std::string OldPrefix, NewPrefix;
getThinLTOOldAndNewPrefix(OldPrefix, NewPrefix);
Backend = createWriteIndexesThinBackend(
OldPrefix, NewPrefix, options::thinlto_emit_imports_files,
options::thinlto_linked_objects_file);
}
Conf.OverrideTriple = options::triple;
Conf.DefaultTriple = sys::getDefaultTargetTriple();
Conf.DiagHandler = diagnosticHandler;
switch (options::TheOutputType) {
case options::OT_NORMAL:
break;
case options::OT_DISABLE:
Conf.PreOptModuleHook = [](size_t Task, const Module &M) { return false; };
break;
case options::OT_BC_ONLY:
Conf.PostInternalizeModuleHook = [](size_t Task, const Module &M) {
std::error_code EC;
raw_fd_ostream OS(output_name, EC, sys::fs::OpenFlags::F_None);
if (EC)
message(LDPL_FATAL, "Failed to write the output file.");
WriteBitcodeToFile(&M, OS, /* ShouldPreserveUseListOrder */ false);
return false;
};
break;
case options::OT_SAVE_TEMPS:
check(Conf.addSaveTemps(output_name + ".",
/* UseInputModulePath */ true));
break;
}
if (!options::sample_profile.empty())
Conf.SampleProfile = options::sample_profile;
return llvm::make_unique<LTO>(std::move(Conf), Backend,
options::ParallelCodeGenParallelismLevel);
}
// Write empty files that may be expected by a distributed build
// system when invoked with thinlto_index_only. This is invoked when
// the linker has decided not to include the given module in the
// final link. Frequently the distributed build system will want to
// confirm that all expected outputs are created based on all of the
// modules provided to the linker.
static void writeEmptyDistributedBuildOutputs(std::string &ModulePath,
std::string &OldPrefix,
std::string &NewPrefix) {
std::string NewModulePath =
getThinLTOOutputFile(ModulePath, OldPrefix, NewPrefix);
std::error_code EC;
{
raw_fd_ostream OS(NewModulePath + ".thinlto.bc", EC,
sys::fs::OpenFlags::F_None);
if (EC)
message(LDPL_FATAL, "Failed to write '%s': %s",
(NewModulePath + ".thinlto.bc").c_str(), EC.message().c_str());
}
if (options::thinlto_emit_imports_files) {
raw_fd_ostream OS(NewModulePath + ".imports", EC,
sys::fs::OpenFlags::F_None);
if (EC)
message(LDPL_FATAL, "Failed to write '%s': %s",
(NewModulePath + ".imports").c_str(), EC.message().c_str());
}
}
/// gold informs us that all symbols have been read. At this point, we use
/// get_symbols to see if any of our definitions have been overridden by a
/// native object file. Then, perform optimization and codegen.
static ld_plugin_status allSymbolsReadHook() {
if (Modules.empty())
return LDPS_OK;
if (unsigned NumOpts = options::extra.size())
cl::ParseCommandLineOptions(NumOpts, &options::extra[0]);
// Map to own RAII objects that manage the file opening and releasing
// interfaces with gold. This is needed only for ThinLTO mode, since
// unlike regular LTO, where addModule will result in the opened file
// being merged into a new combined module, we need to keep these files open
// through Lto->run().
DenseMap<void *, std::unique_ptr<PluginInputFile>> HandleToInputFile;
std::unique_ptr<LTO> Lto = createLTO();
std::string OldPrefix, NewPrefix;
if (options::thinlto_index_only)
getThinLTOOldAndNewPrefix(OldPrefix, NewPrefix);
[ThinLTO] Add support for emitting minimized bitcode for thin link Summary: The cumulative size of the bitcode files for a very large application can be huge, particularly with -g. In a distributed build environment, all of these files must be sent to the remote build node that performs the thin link step, and this can exceed size limits. The thin link actually only needs the summary along with a bitcode symbol table. Until we have a proper bitcode symbol table, simply stripping the debug metadata results in significant size reduction. Add support for an option to additionally emit minimized bitcode modules, just for use in the thin link step, which for now just strips all debug metadata. I plan to add a cc1 option so this can be invoked easily during the compile step. However, care must be taken to ensure that these minimized thin link bitcode files produce the same index as with the original bitcode files, as these original bitcode files will be used in the backends. Specifically: 1) The module hash used for caching is typically produced by hashing the written bitcode, and we want to include the hash that would correspond to the original bitcode file. This is because we want to ensure that changes in the stripped portions affect caching. Added plumbing to emit the same module hash in the minimized thin link bitcode file. 2) The module paths in the index are constructed from the module ID of each thin linked bitcode, and typically is automatically generated from the input file path. This is the path used for finding the modules to import from, and obviously we need this to point to the original bitcode files. Added gold-plugin support to take a suffix replacement during the thin link that is used to override the identifier on the MemoryBufferRef constructed from the loaded thin link bitcode file. The assumption is that the build system can specify that the minimized bitcode file has a name that is similar but uses a different suffix (e.g. out.thinlink.bc instead of out.o). Added various tests to ensure that we get identical index files out of the thin link step. Reviewers: mehdi_amini, pcc Subscribers: Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D31027 llvm-svn: 298638
2017-03-23 20:47:39 +01:00
std::string OldSuffix, NewSuffix;
getThinLTOOldAndNewSuffix(OldSuffix, NewSuffix);
// Set for owning string objects used as buffer identifiers.
StringSet<> ObjectFilenames;
for (claimed_file &F : Modules) {
if (options::thinlto && !HandleToInputFile.count(F.leader_handle))
HandleToInputFile.insert(std::make_pair(
F.leader_handle, llvm::make_unique<PluginInputFile>(F.handle)));
const void *View = getSymbolsAndView(F);
[ThinLTO] Add support for emitting minimized bitcode for thin link Summary: The cumulative size of the bitcode files for a very large application can be huge, particularly with -g. In a distributed build environment, all of these files must be sent to the remote build node that performs the thin link step, and this can exceed size limits. The thin link actually only needs the summary along with a bitcode symbol table. Until we have a proper bitcode symbol table, simply stripping the debug metadata results in significant size reduction. Add support for an option to additionally emit minimized bitcode modules, just for use in the thin link step, which for now just strips all debug metadata. I plan to add a cc1 option so this can be invoked easily during the compile step. However, care must be taken to ensure that these minimized thin link bitcode files produce the same index as with the original bitcode files, as these original bitcode files will be used in the backends. Specifically: 1) The module hash used for caching is typically produced by hashing the written bitcode, and we want to include the hash that would correspond to the original bitcode file. This is because we want to ensure that changes in the stripped portions affect caching. Added plumbing to emit the same module hash in the minimized thin link bitcode file. 2) The module paths in the index are constructed from the module ID of each thin linked bitcode, and typically is automatically generated from the input file path. This is the path used for finding the modules to import from, and obviously we need this to point to the original bitcode files. Added gold-plugin support to take a suffix replacement during the thin link that is used to override the identifier on the MemoryBufferRef constructed from the loaded thin link bitcode file. The assumption is that the build system can specify that the minimized bitcode file has a name that is similar but uses a different suffix (e.g. out.thinlink.bc instead of out.o). Added various tests to ensure that we get identical index files out of the thin link step. Reviewers: mehdi_amini, pcc Subscribers: Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D31027 llvm-svn: 298638
2017-03-23 20:47:39 +01:00
// In case we are thin linking with a minimized bitcode file, ensure
// the module paths encoded in the index reflect where the backends
// will locate the full bitcode files for compiling/importing.
std::string Identifier =
getThinLTOObjectFileName(F.name, OldSuffix, NewSuffix);
auto ObjFilename = ObjectFilenames.insert(Identifier);
assert(ObjFilename.second);
if (!View) {
if (options::thinlto_index_only)
// Write empty output files that may be expected by the distributed
// build system.
[ThinLTO] Add support for emitting minimized bitcode for thin link Summary: The cumulative size of the bitcode files for a very large application can be huge, particularly with -g. In a distributed build environment, all of these files must be sent to the remote build node that performs the thin link step, and this can exceed size limits. The thin link actually only needs the summary along with a bitcode symbol table. Until we have a proper bitcode symbol table, simply stripping the debug metadata results in significant size reduction. Add support for an option to additionally emit minimized bitcode modules, just for use in the thin link step, which for now just strips all debug metadata. I plan to add a cc1 option so this can be invoked easily during the compile step. However, care must be taken to ensure that these minimized thin link bitcode files produce the same index as with the original bitcode files, as these original bitcode files will be used in the backends. Specifically: 1) The module hash used for caching is typically produced by hashing the written bitcode, and we want to include the hash that would correspond to the original bitcode file. This is because we want to ensure that changes in the stripped portions affect caching. Added plumbing to emit the same module hash in the minimized thin link bitcode file. 2) The module paths in the index are constructed from the module ID of each thin linked bitcode, and typically is automatically generated from the input file path. This is the path used for finding the modules to import from, and obviously we need this to point to the original bitcode files. Added gold-plugin support to take a suffix replacement during the thin link that is used to override the identifier on the MemoryBufferRef constructed from the loaded thin link bitcode file. The assumption is that the build system can specify that the minimized bitcode file has a name that is similar but uses a different suffix (e.g. out.thinlink.bc instead of out.o). Added various tests to ensure that we get identical index files out of the thin link step. Reviewers: mehdi_amini, pcc Subscribers: Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D31027 llvm-svn: 298638
2017-03-23 20:47:39 +01:00
writeEmptyDistributedBuildOutputs(Identifier, OldPrefix, NewPrefix);
continue;
}
[ThinLTO] Add support for emitting minimized bitcode for thin link Summary: The cumulative size of the bitcode files for a very large application can be huge, particularly with -g. In a distributed build environment, all of these files must be sent to the remote build node that performs the thin link step, and this can exceed size limits. The thin link actually only needs the summary along with a bitcode symbol table. Until we have a proper bitcode symbol table, simply stripping the debug metadata results in significant size reduction. Add support for an option to additionally emit minimized bitcode modules, just for use in the thin link step, which for now just strips all debug metadata. I plan to add a cc1 option so this can be invoked easily during the compile step. However, care must be taken to ensure that these minimized thin link bitcode files produce the same index as with the original bitcode files, as these original bitcode files will be used in the backends. Specifically: 1) The module hash used for caching is typically produced by hashing the written bitcode, and we want to include the hash that would correspond to the original bitcode file. This is because we want to ensure that changes in the stripped portions affect caching. Added plumbing to emit the same module hash in the minimized thin link bitcode file. 2) The module paths in the index are constructed from the module ID of each thin linked bitcode, and typically is automatically generated from the input file path. This is the path used for finding the modules to import from, and obviously we need this to point to the original bitcode files. Added gold-plugin support to take a suffix replacement during the thin link that is used to override the identifier on the MemoryBufferRef constructed from the loaded thin link bitcode file. The assumption is that the build system can specify that the minimized bitcode file has a name that is similar but uses a different suffix (e.g. out.thinlink.bc instead of out.o). Added various tests to ensure that we get identical index files out of the thin link step. Reviewers: mehdi_amini, pcc Subscribers: Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D31027 llvm-svn: 298638
2017-03-23 20:47:39 +01:00
addModule(*Lto, F, View, ObjFilename.first->first());
}
SmallString<128> Filename;
// Note that getOutputFileName will append a unique ID for each task
if (!options::obj_path.empty())
Filename = options::obj_path;
else if (options::TheOutputType == options::OT_SAVE_TEMPS)
Filename = output_name + ".o";
bool SaveTemps = !Filename.empty();
size_t MaxTasks = Lto->getMaxTasks();
std::vector<uintptr_t> IsTemporary(MaxTasks);
std::vector<SmallString<128>> Filenames(MaxTasks);
auto AddStream =
[&](size_t Task) -> std::unique_ptr<lto::NativeObjectStream> {
IsTemporary[Task] = !SaveTemps;
int FD = getOutputFileName(Filename, /*TempOutFile=*/!SaveTemps,
Filenames[Task], Task);
return llvm::make_unique<lto::NativeObjectStream>(
llvm::make_unique<llvm::raw_fd_ostream>(FD, true));
};
auto AddBuffer = [&](size_t Task, std::unique_ptr<MemoryBuffer> MB,
StringRef Path) {
// Note that this requires that the memory buffers provided to AddBuffer are
// backed by a file.
Filenames[Task] = Path;
};
NativeObjectCache Cache;
if (!options::cache_dir.empty())
Cache = check(localCache(options::cache_dir, AddBuffer));
check(Lto->run(AddStream, Cache));
if (options::TheOutputType == options::OT_DISABLE ||
options::TheOutputType == options::OT_BC_ONLY)
return LDPS_OK;
if (options::thinlto_index_only) {
if (llvm::AreStatisticsEnabled())
llvm::PrintStatistics();
cleanup_hook();
exit(0);
}
for (unsigned I = 0; I != MaxTasks; ++I)
if (!Filenames[I].empty())
recordFile(Filenames[I].str(), IsTemporary[I]);
if (!options::extra_library_path.empty() &&
set_extra_library_path(options::extra_library_path.c_str()) != LDPS_OK)
message(LDPL_FATAL, "Unable to set the extra library path.");
return LDPS_OK;
}
static ld_plugin_status all_symbols_read_hook(void) {
ld_plugin_status Ret = allSymbolsReadHook();
llvm_shutdown();
if (options::TheOutputType == options::OT_BC_ONLY ||
options::TheOutputType == options::OT_DISABLE) {
if (options::TheOutputType == options::OT_DISABLE) {
// Remove the output file here since ld.bfd creates the output file
// early.
std::error_code EC = sys::fs::remove(output_name);
if (EC)
message(LDPL_ERROR, "Failed to delete '%s': %s", output_name.c_str(),
EC.message().c_str());
}
exit(0);
}
return Ret;
}
static ld_plugin_status cleanup_hook(void) {
2014-07-30 03:52:40 +02:00
for (std::string &Name : Cleanup) {
std::error_code EC = sys::fs::remove(Name);
if (EC)
2014-07-30 03:52:40 +02:00
message(LDPL_ERROR, "Failed to delete '%s': %s", Name.c_str(),
EC.message().c_str());
}
// Prune cache
if (!options::cache_policy.empty()) {
CachePruningPolicy policy = check(parseCachePruningPolicy(options::cache_policy));
pruneCache(options::cache_dir, policy);
}
return LDPS_OK;
}