2009-02-03 15:13:24 +08:00
|
|
|
//===-- 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 .
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-01-13 16:04:33 +08:00
|
|
|
#include "llvm/ADT/StringSet.h"
|
2015-01-15 10:16:27 +08:00
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
2015-02-02 13:47:30 +08:00
|
|
|
#include "llvm/Analysis/TargetTransformInfo.h"
|
2014-08-22 04:28:55 +08:00
|
|
|
#include "llvm/Bitcode/ReaderWriter.h"
|
|
|
|
#include "llvm/CodeGen/Analysis.h"
|
2014-06-20 05:14:13 +08:00
|
|
|
#include "llvm/CodeGen/CommandFlags.h"
|
2015-09-02 04:40:22 +08:00
|
|
|
#include "llvm/CodeGen/ParallelCG.h"
|
2016-04-18 17:17:29 +08:00
|
|
|
#include "llvm/Config/config.h" // plugin-api.h requires HAVE_STDINT_H
|
2015-03-31 05:36:43 +08:00
|
|
|
#include "llvm/IR/AutoUpgrade.h"
|
2014-09-10 04:08:22 +08:00
|
|
|
#include "llvm/IR/Constants.h"
|
2015-01-10 08:07:30 +08:00
|
|
|
#include "llvm/IR/DiagnosticInfo.h"
|
|
|
|
#include "llvm/IR/DiagnosticPrinter.h"
|
2014-08-22 04:28:55 +08:00
|
|
|
#include "llvm/IR/LLVMContext.h"
|
2015-02-13 18:01:29 +08:00
|
|
|
#include "llvm/IR/LegacyPassManager.h"
|
2014-08-22 04:28:55 +08:00
|
|
|
#include "llvm/IR/Module.h"
|
|
|
|
#include "llvm/IR/Verifier.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 09:46:41 +08:00
|
|
|
#include "llvm/LTO/LTO.h"
|
2015-12-10 22:19:35 +08:00
|
|
|
#include "llvm/Linker/IRMover.h"
|
2014-08-22 04:28:55 +08:00
|
|
|
#include "llvm/MC/SubtargetFeature.h"
|
2015-12-10 03:45:55 +08:00
|
|
|
#include "llvm/Object/IRObjectFile.h"
|
2016-04-18 17:17:29 +08:00
|
|
|
#include "llvm/Object/ModuleSummaryIndexObjectFile.h"
|
2014-08-22 04:28:55 +08:00
|
|
|
#include "llvm/Support/Host.h"
|
2014-11-26 04:52:49 +08:00
|
|
|
#include "llvm/Support/ManagedStatic.h"
|
2012-12-04 18:44:52 +08:00
|
|
|
#include "llvm/Support/MemoryBuffer.h"
|
2016-05-17 22:45:30 +08:00
|
|
|
#include "llvm/Support/Path.h"
|
2014-08-22 04:28:55 +08:00
|
|
|
#include "llvm/Support/TargetRegistry.h"
|
2014-06-20 05:14:13 +08:00
|
|
|
#include "llvm/Support/TargetSelect.h"
|
2016-03-05 01:06:02 +08:00
|
|
|
#include "llvm/Support/ThreadPool.h"
|
2015-12-10 03:45:55 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2016-03-05 01:06:02 +08:00
|
|
|
#include "llvm/Support/thread.h"
|
2014-08-22 04:28:55 +08:00
|
|
|
#include "llvm/Transforms/IPO.h"
|
2016-05-10 21:48:23 +08:00
|
|
|
#include "llvm/Transforms/IPO/FunctionImport.h"
|
2014-08-22 04:28:55 +08:00
|
|
|
#include "llvm/Transforms/IPO/PassManagerBuilder.h"
|
2016-03-05 01:06:02 +08:00
|
|
|
#include "llvm/Transforms/Utils/FunctionImportUtils.h"
|
2014-08-22 04:28:55 +08:00
|
|
|
#include "llvm/Transforms/Utils/GlobalStatus.h"
|
2014-08-23 07:26:10 +08:00
|
|
|
#include "llvm/Transforms/Utils/ValueMapper.h"
|
2009-02-03 15:13:24 +08:00
|
|
|
#include <list>
|
2014-01-13 16:04:33 +08:00
|
|
|
#include <plugin-api.h>
|
2014-06-13 01:38:55 +08:00
|
|
|
#include <system_error>
|
2009-02-03 15:13:24 +08:00
|
|
|
#include <vector>
|
|
|
|
|
2014-02-12 01:30:18 +08:00
|
|
|
// FIXME: remove this declaration when we stop maintaining Ubuntu Quantal and
|
|
|
|
// Precise and Debian Wheezy (binutils 2.23 is required)
|
2016-03-04 08:23:29 +08:00
|
|
|
#define LDPO_PIE 3
|
|
|
|
|
|
|
|
#define LDPT_GET_SYMBOLS_V3 28
|
2014-02-12 01:30:18 +08:00
|
|
|
|
2009-02-03 15:13:24 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
2015-12-17 00:34:06 +08:00
|
|
|
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;
|
|
|
|
|
2009-02-03 15:13:24 +08:00
|
|
|
namespace {
|
2014-06-20 09:37:35 +08:00
|
|
|
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 09:46:41 +08:00
|
|
|
void *leader_handle;
|
2014-06-20 09:37:35 +08:00
|
|
|
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 09:46:41 +08:00
|
|
|
off_t filesize;
|
|
|
|
std::string name;
|
2014-06-20 09:37:35 +08:00
|
|
|
};
|
2015-12-10 22:19:35 +08:00
|
|
|
|
2015-12-17 00:34:06 +08:00
|
|
|
/// RAII wrapper to manage opening and releasing of a ld_plugin_input_file.
|
|
|
|
struct PluginInputFile {
|
2015-12-17 05:37:48 +08:00
|
|
|
void *Handle;
|
2016-03-05 01:06:02 +08:00
|
|
|
std::unique_ptr<ld_plugin_input_file> File;
|
2015-12-17 00:34:06 +08:00
|
|
|
|
2015-12-17 05:37:48 +08:00
|
|
|
PluginInputFile(void *Handle) : Handle(Handle) {
|
2016-03-05 01:06:02 +08:00
|
|
|
File = llvm::make_unique<ld_plugin_input_file>();
|
|
|
|
if (get_input_file(Handle, File.get()) != LDPS_OK)
|
2015-12-17 00:34:06 +08:00
|
|
|
message(LDPL_FATAL, "Failed to get file information");
|
|
|
|
}
|
|
|
|
~PluginInputFile() {
|
2016-03-05 01:06:02 +08:00
|
|
|
// 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");
|
2015-12-17 00:34:06 +08:00
|
|
|
}
|
2016-03-05 01:06:02 +08:00
|
|
|
|
|
|
|
ld_plugin_input_file &file() { return *File; }
|
|
|
|
|
|
|
|
PluginInputFile(PluginInputFile &&RHS) = default;
|
|
|
|
PluginInputFile &operator=(PluginInputFile &&RHS) = default;
|
2015-12-17 00:34:06 +08:00
|
|
|
};
|
|
|
|
|
2015-12-10 22:19:35 +08:00
|
|
|
struct ResolutionInfo {
|
2016-03-11 08:51:57 +08:00
|
|
|
uint64_t CommonSize = 0;
|
|
|
|
unsigned CommonAlign = 0;
|
2015-12-10 22:19:35 +08:00
|
|
|
bool IsLinkonceOdr = true;
|
|
|
|
bool UnnamedAddr = true;
|
|
|
|
GlobalValue::VisibilityTypes Visibility = GlobalValue::DefaultVisibility;
|
|
|
|
bool CommonInternal = false;
|
|
|
|
bool UseCommon = false;
|
|
|
|
};
|
2016-03-05 01:06:02 +08:00
|
|
|
|
|
|
|
/// Class to own information used by a task or during its cleanup for a
|
|
|
|
/// ThinLTO backend instantiation.
|
|
|
|
class ThinLTOTaskInfo {
|
|
|
|
/// The output stream the task will codegen into.
|
|
|
|
std::unique_ptr<raw_fd_ostream> OS;
|
|
|
|
|
|
|
|
/// The file name corresponding to the output stream, used during cleanup.
|
|
|
|
std::string Filename;
|
|
|
|
|
|
|
|
/// Flag indicating whether the output file is a temp file that must be
|
|
|
|
/// added to the cleanup list during cleanup.
|
|
|
|
bool TempOutFile;
|
|
|
|
|
|
|
|
public:
|
[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 09:46:41 +08:00
|
|
|
ThinLTOTaskInfo(std::unique_ptr<raw_fd_ostream> OS, std::string Filename,
|
|
|
|
bool TempOutFile)
|
|
|
|
: OS(std::move(OS)), Filename(Filename), TempOutFile(TempOutFile) {}
|
2016-03-05 01:06:02 +08:00
|
|
|
|
|
|
|
/// Performs task related cleanup activities that must be done
|
|
|
|
/// single-threaded (i.e. call backs to gold).
|
|
|
|
void cleanup();
|
|
|
|
};
|
2014-06-20 09:37:35 +08:00
|
|
|
}
|
2009-02-03 15:13:24 +08:00
|
|
|
|
2014-07-30 05:46:05 +08:00
|
|
|
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;
|
2016-05-19 06:04:49 +08:00
|
|
|
static Optional<Reloc::Model> RelocationModel;
|
2014-06-20 09:37:35 +08:00
|
|
|
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 09:46:41 +08:00
|
|
|
static DenseMap<int, void *> FDToLeaderHandle;
|
2015-12-10 22:19:35 +08:00
|
|
|
static StringMap<ResolutionInfo> ResInfo;
|
2014-06-20 09:37:35 +08:00
|
|
|
static std::vector<std::string> Cleanup;
|
2014-06-20 05:14:13 +08:00
|
|
|
static llvm::TargetOptions TargetOpts;
|
2016-03-05 00:36:06 +08:00
|
|
|
static std::string DefaultTriple = sys::getDefaultTargetTriple();
|
2009-02-03 15:13:24 +08:00
|
|
|
|
2009-10-29 02:55:55 +08:00
|
|
|
namespace options {
|
2014-11-25 05:18:14 +08:00
|
|
|
enum OutputType {
|
|
|
|
OT_NORMAL,
|
|
|
|
OT_DISABLE,
|
|
|
|
OT_BC_ONLY,
|
|
|
|
OT_SAVE_TEMPS
|
|
|
|
};
|
2010-04-16 08:42:57 +08:00
|
|
|
static bool generate_api_file = false;
|
2014-11-25 05:18:14 +08:00
|
|
|
static OutputType TheOutputType = OT_NORMAL;
|
2015-03-20 06:01:00 +08:00
|
|
|
static unsigned OptLevel = 2;
|
2016-03-05 00:36:06 +08:00
|
|
|
// Default parallelism of 0 used to indicate that user did not specify.
|
|
|
|
// Actual parallelism default value depends on implementation.
|
2016-03-05 01:06:02 +08:00
|
|
|
// Currently, code generation defaults to no parallelism, whereas
|
|
|
|
// ThinLTO uses the hardware_concurrency as the default.
|
2016-03-05 00:36:06 +08:00
|
|
|
static unsigned Parallelism = 0;
|
2015-09-17 02:06:45 +08:00
|
|
|
#ifdef NDEBUG
|
|
|
|
static bool DisableVerify = true;
|
|
|
|
#else
|
|
|
|
static bool DisableVerify = false;
|
|
|
|
#endif
|
2013-08-13 05:07:31 +08:00
|
|
|
static std::string obj_path;
|
2010-06-24 04:20:59 +08:00
|
|
|
static std::string extra_library_path;
|
2010-08-10 05:09:46 +08:00
|
|
|
static std::string triple;
|
2010-08-11 08:15:13 +08:00
|
|
|
static std::string mcpu;
|
2015-10-04 22:33:43 +08:00
|
|
|
// 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;
|
2016-03-05 01:06:02 +08:00
|
|
|
// If false, all ThinLTO backend compilations through code gen are performed
|
|
|
|
// using multiple threads in the gold-plugin, before handing control back to
|
2016-05-10 21:48:23 +08:00
|
|
|
// gold. If true, write individual backend index files which reflect
|
|
|
|
// the import decisions, and exit afterwards. The assumption is
|
2016-03-05 01:06:02 +08:00
|
|
|
// that the build system will launch the backend processes.
|
|
|
|
static bool thinlto_index_only = false;
|
2016-05-10 23:54:09 +08:00
|
|
|
// 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;
|
2016-05-17 22:45:30 +08:00
|
|
|
// 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;
|
2009-10-29 02:55:55 +08:00
|
|
|
// Additional options to pass into the code generator.
|
2010-06-04 01:10:17 +08:00
|
|
|
// Note: This array will contain all plugin options which are not claimed
|
2009-10-29 02:55:55 +08:00
|
|
|
// as plugin exclusive to pass to the code generator.
|
2010-06-04 01:10:17 +08:00
|
|
|
// For example, "generate-api-file" and "as"options are for the plugin
|
2009-10-29 02:55:55 +08:00
|
|
|
// use only and will not be passed.
|
2014-07-30 03:17:44 +08:00
|
|
|
static std::vector<const char *> extra;
|
2009-10-29 02:55:55 +08:00
|
|
|
|
2015-08-06 05:16:02 +08:00
|
|
|
static void process_plugin_option(const char *opt_)
|
2009-10-29 02:55:55 +08:00
|
|
|
{
|
2014-07-30 05:46:05 +08:00
|
|
|
if (opt_ == nullptr)
|
2009-10-29 02:55:55 +08:00
|
|
|
return;
|
2010-06-08 00:45:22 +08:00
|
|
|
llvm::StringRef opt = opt_;
|
2009-10-29 02:55:55 +08:00
|
|
|
|
2010-06-08 00:45:22 +08:00
|
|
|
if (opt == "generate-api-file") {
|
2009-10-29 02:55:55 +08:00
|
|
|
generate_api_file = true;
|
2010-08-11 08:15:13 +08:00
|
|
|
} else if (opt.startswith("mcpu=")) {
|
|
|
|
mcpu = opt.substr(strlen("mcpu="));
|
2010-06-24 04:20:59 +08:00
|
|
|
} else if (opt.startswith("extra-library-path=")) {
|
|
|
|
extra_library_path = opt.substr(strlen("extra_library_path="));
|
2010-08-11 00:32:15 +08:00
|
|
|
} else if (opt.startswith("mtriple=")) {
|
2010-08-10 05:09:46 +08:00
|
|
|
triple = opt.substr(strlen("mtriple="));
|
2013-08-13 05:07:31 +08:00
|
|
|
} else if (opt.startswith("obj-path=")) {
|
|
|
|
obj_path = opt.substr(strlen("obj-path="));
|
2010-06-08 00:45:22 +08:00
|
|
|
} else if (opt == "emit-llvm") {
|
2014-11-25 05:18:14 +08:00
|
|
|
TheOutputType = OT_BC_ONLY;
|
2014-10-30 07:54:45 +08:00
|
|
|
} else if (opt == "save-temps") {
|
2014-11-25 05:18:14 +08:00
|
|
|
TheOutputType = OT_SAVE_TEMPS;
|
|
|
|
} else if (opt == "disable-output") {
|
|
|
|
TheOutputType = OT_DISABLE;
|
2015-10-04 22:33:43 +08:00
|
|
|
} else if (opt == "thinlto") {
|
|
|
|
thinlto = true;
|
2016-03-05 01:06:02 +08:00
|
|
|
} else if (opt == "thinlto-index-only") {
|
|
|
|
thinlto_index_only = true;
|
2016-05-10 23:54:09 +08:00
|
|
|
} else if (opt == "thinlto-emit-imports-files") {
|
|
|
|
thinlto_emit_imports_files = true;
|
2016-05-17 22:45:30 +08:00
|
|
|
} else if (opt.startswith("thinlto-prefix-replace=")) {
|
|
|
|
thinlto_prefix_replace = opt.substr(strlen("thinlto-prefix-replace="));
|
2016-05-18 02:43:22 +08:00
|
|
|
if (thinlto_prefix_replace.find(";") == std::string::npos)
|
|
|
|
message(LDPL_FATAL, "thinlto-prefix-replace expects 'old;new' format");
|
2015-03-20 06:01:00 +08:00
|
|
|
} else if (opt.size() == 2 && opt[0] == 'O') {
|
|
|
|
if (opt[1] < '0' || opt[1] > '3')
|
2015-09-02 04:40:22 +08:00
|
|
|
message(LDPL_FATAL, "Optimization level must be between 0 and 3");
|
2015-03-20 06:01:00 +08:00
|
|
|
OptLevel = opt[1] - '0';
|
2015-09-02 04:40:22 +08:00
|
|
|
} else if (opt.startswith("jobs=")) {
|
|
|
|
if (StringRef(opt_ + 5).getAsInteger(10, Parallelism))
|
|
|
|
message(LDPL_FATAL, "Invalid parallelism level: %s", opt_ + 5);
|
2015-09-17 02:06:45 +08:00
|
|
|
} else if (opt == "disable-verify") {
|
|
|
|
DisableVerify = true;
|
2009-10-29 02:55:55 +08:00
|
|
|
} else {
|
|
|
|
// Save this option to pass to the code generator.
|
2014-08-22 04:28:55 +08:00
|
|
|
// ParseCommandLineOptions() expects argv[0] to be program name. Lazily
|
|
|
|
// add that.
|
|
|
|
if (extra.empty())
|
|
|
|
extra.push_back("LLVMgold");
|
|
|
|
|
2014-07-30 03:17:44 +08:00
|
|
|
extra.push_back(opt_);
|
2009-10-29 02:55:55 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-04-16 08:42:57 +08:00
|
|
|
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);
|
2009-02-03 15:13:24 +08:00
|
|
|
|
|
|
|
extern "C" ld_plugin_status onload(ld_plugin_tv *tv);
|
|
|
|
ld_plugin_status onload(ld_plugin_tv *tv) {
|
2014-07-04 07:28:03 +08:00
|
|
|
InitializeAllTargetInfos();
|
|
|
|
InitializeAllTargets();
|
|
|
|
InitializeAllTargetMCs();
|
|
|
|
InitializeAllAsmParsers();
|
|
|
|
InitializeAllAsmPrinters();
|
|
|
|
|
2009-02-03 15:13:24 +08:00
|
|
|
// 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;
|
2014-06-20 05:14:13 +08:00
|
|
|
bool RegisteredAllSymbolsRead = false;
|
2009-02-03 15:13:24 +08:00
|
|
|
|
|
|
|
for (; tv->tv_tag != LDPT_NULL; ++tv) {
|
2016-03-04 08:23:29 +08:00
|
|
|
// 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
|
|
|
|
case LDPO_DYN: // .so
|
|
|
|
case LDPO_PIE: // position independent executable
|
|
|
|
RelocationModel = Reloc::PIC_;
|
2011-04-08 05:11:00 +08:00
|
|
|
break;
|
2016-03-04 08:23:29 +08:00
|
|
|
case LDPO_EXEC: // .exe
|
|
|
|
RelocationModel = Reloc::Static;
|
2009-02-03 15:13:24 +08:00
|
|
|
break;
|
|
|
|
default:
|
2016-03-04 08:23:29 +08:00
|
|
|
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-03 15:13:24 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-02-18 16:30:15 +08:00
|
|
|
if (!registeredClaimFile) {
|
2014-07-30 08:38:58 +08:00
|
|
|
message(LDPL_ERROR, "register_claim_file not passed to LLVMgold.");
|
2009-02-19 01:49:06 +08:00
|
|
|
return LDPS_ERR;
|
|
|
|
}
|
2009-02-18 16:30:15 +08:00
|
|
|
if (!add_symbols) {
|
2014-07-30 08:38:58 +08:00
|
|
|
message(LDPL_ERROR, "add_symbols not passed to LLVMgold.");
|
2009-02-19 01:49:06 +08:00
|
|
|
return LDPS_ERR;
|
|
|
|
}
|
2009-02-03 15:13:24 +08:00
|
|
|
|
2014-06-20 06:20:07 +08:00
|
|
|
if (!RegisteredAllSymbolsRead)
|
|
|
|
return LDPS_OK;
|
2014-06-20 05:14:13 +08:00
|
|
|
|
2014-08-22 04:28:55 +08:00
|
|
|
if (!get_input_file) {
|
|
|
|
message(LDPL_ERROR, "get_input_file not passed to LLVMgold.");
|
|
|
|
return LDPS_ERR;
|
2014-06-20 06:54:47 +08:00
|
|
|
}
|
2014-08-22 04:28:55 +08:00
|
|
|
if (!release_input_file) {
|
2016-03-30 20:20:53 +08:00
|
|
|
message(LDPL_ERROR, "release_input_file not passed to LLVMgold.");
|
2014-08-22 04:28:55 +08:00
|
|
|
return LDPS_ERR;
|
2014-06-27 04:43:27 +08:00
|
|
|
}
|
|
|
|
|
2009-02-03 15:13:24 +08:00
|
|
|
return LDPS_OK;
|
|
|
|
}
|
|
|
|
|
2014-08-23 07:26:10 +08:00
|
|
|
static const GlobalObject *getBaseObject(const GlobalValue &GV) {
|
|
|
|
if (auto *GA = dyn_cast<GlobalAlias>(&GV))
|
|
|
|
return GA->getBaseObject();
|
|
|
|
return cast<GlobalObject>(&GV);
|
|
|
|
}
|
|
|
|
|
2014-12-10 00:13:59 +08:00
|
|
|
static bool shouldSkip(uint32_t Symflags) {
|
|
|
|
if (!(Symflags & object::BasicSymbolRef::SF_Global))
|
|
|
|
return true;
|
|
|
|
if (Symflags & object::BasicSymbolRef::SF_FormatSpecific)
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-11-19 18:43:44 +08:00
|
|
|
static void diagnosticHandler(const DiagnosticInfo &DI) {
|
2015-03-03 03:08:03 +08:00
|
|
|
if (const auto *BDI = dyn_cast<BitcodeDiagnosticInfo>(&DI)) {
|
|
|
|
std::error_code EC = BDI->getError();
|
|
|
|
if (EC == BitcodeError::InvalidBitcodeSignature)
|
|
|
|
return;
|
|
|
|
}
|
2015-01-10 08:07:30 +08:00
|
|
|
|
|
|
|
std::string ErrStorage;
|
|
|
|
{
|
|
|
|
raw_string_ostream OS(ErrStorage);
|
|
|
|
DiagnosticPrinterRawOStream DP(OS);
|
|
|
|
DI.print(DP);
|
|
|
|
}
|
2015-03-03 03:08:03 +08:00
|
|
|
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:
|
2015-03-05 02:51:45 +08:00
|
|
|
case DS_Remark:
|
2015-03-03 03:08:03 +08:00
|
|
|
Level = LDPL_INFO;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
message(Level, "LLVM gold plugin: %s", ErrStorage.c_str());
|
2015-01-10 08:07:30 +08:00
|
|
|
}
|
|
|
|
|
2015-11-19 18:43:44 +08:00
|
|
|
static void diagnosticHandlerForContext(const DiagnosticInfo &DI,
|
|
|
|
void *Context) {
|
|
|
|
diagnosticHandler(DI);
|
|
|
|
}
|
|
|
|
|
2015-12-10 22:19:35 +08:00
|
|
|
static GlobalValue::VisibilityTypes
|
|
|
|
getMinVisibility(GlobalValue::VisibilityTypes A,
|
|
|
|
GlobalValue::VisibilityTypes B) {
|
|
|
|
if (A == GlobalValue::HiddenVisibility)
|
|
|
|
return A;
|
|
|
|
if (B == GlobalValue::HiddenVisibility)
|
|
|
|
return B;
|
|
|
|
if (A == GlobalValue::ProtectedVisibility)
|
|
|
|
return A;
|
|
|
|
return B;
|
|
|
|
}
|
|
|
|
|
2014-07-06 22:31:22 +08:00
|
|
|
/// 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.
|
2010-04-16 08:42:57 +08:00
|
|
|
static ld_plugin_status claim_file_hook(const ld_plugin_input_file *file,
|
|
|
|
int *claimed) {
|
2014-08-22 04:28:55 +08:00
|
|
|
LLVMContext Context;
|
2014-08-28 04:25:55 +08:00
|
|
|
MemoryBufferRef BufferRef;
|
|
|
|
std::unique_ptr<MemoryBuffer> Buffer;
|
2011-04-08 05:11:00 +08:00
|
|
|
if (get_view) {
|
2014-08-22 04:28:55 +08:00
|
|
|
const void *view;
|
2011-04-08 05:11:00 +08:00
|
|
|
if (get_view(file->handle, &view) != LDPS_OK) {
|
2014-07-30 08:38:58 +08:00
|
|
|
message(LDPL_ERROR, "Failed to get a view of %s", file->name);
|
2011-04-08 05:11:00 +08:00
|
|
|
return LDPS_ERR;
|
|
|
|
}
|
2015-08-06 05:16:02 +08:00
|
|
|
BufferRef =
|
|
|
|
MemoryBufferRef(StringRef((const char *)view, file->filesize), "");
|
2011-09-13 05:47:50 +08:00
|
|
|
} else {
|
2011-09-16 07:13:00 +08:00
|
|
|
int64_t offset = 0;
|
2009-02-05 12:14:23 +08:00
|
|
|
// Gold has found what might be IR part-way inside of a file, such as
|
|
|
|
// an .a archive.
|
2011-09-13 05:47:50 +08:00
|
|
|
if (file->offset) {
|
|
|
|
offset = file->offset;
|
|
|
|
}
|
2014-07-07 01:43:13 +08:00
|
|
|
ErrorOr<std::unique_ptr<MemoryBuffer>> BufferOrErr =
|
|
|
|
MemoryBuffer::getOpenFileSlice(file->fd, file->name, file->filesize,
|
|
|
|
offset);
|
|
|
|
if (std::error_code EC = BufferOrErr.getError()) {
|
2014-07-30 08:38:58 +08:00
|
|
|
message(LDPL_ERROR, EC.message().c_str());
|
2011-09-13 05:47:50 +08:00
|
|
|
return LDPS_ERR;
|
|
|
|
}
|
2014-08-28 04:25:55 +08:00
|
|
|
Buffer = std::move(BufferOrErr.get());
|
|
|
|
BufferRef = Buffer->getMemBufferRef();
|
2011-02-09 06:40:47 +08:00
|
|
|
}
|
2011-09-13 05:47:50 +08:00
|
|
|
|
2015-11-19 18:43:44 +08:00
|
|
|
Context.setDiagnosticHandler(diagnosticHandlerForContext);
|
2014-09-04 01:59:23 +08:00
|
|
|
ErrorOr<std::unique_ptr<object::IRObjectFile>> ObjOrErr =
|
2014-12-10 04:36:13 +08:00
|
|
|
object::IRObjectFile::create(BufferRef, Context);
|
2014-08-22 04:28:55 +08:00
|
|
|
std::error_code EC = ObjOrErr.getError();
|
2015-01-10 08:07:30 +08:00
|
|
|
if (EC == object::object_error::invalid_file_type ||
|
2014-09-19 05:28:49 +08:00
|
|
|
EC == object::object_error::bitcode_section_not_found)
|
2011-09-13 05:47:50 +08:00
|
|
|
return LDPS_OK;
|
|
|
|
|
2014-07-30 04:46:19 +08:00
|
|
|
*claimed = 1;
|
|
|
|
|
2014-08-22 04:28:55 +08:00
|
|
|
if (EC) {
|
2014-07-30 08:38:58 +08:00
|
|
|
message(LDPL_ERROR, "LLVM gold plugin has failed to create LTO module: %s",
|
2014-08-22 04:28:55 +08:00
|
|
|
EC.message().c_str());
|
2014-07-30 04:46:19 +08:00
|
|
|
return LDPS_ERR;
|
2011-09-09 08:14:04 +08:00
|
|
|
}
|
2014-09-04 01:59:23 +08:00
|
|
|
std::unique_ptr<object::IRObjectFile> Obj = std::move(*ObjOrErr);
|
2009-02-03 15:13:24 +08:00
|
|
|
|
|
|
|
Modules.resize(Modules.size() + 1);
|
|
|
|
claimed_file &cf = Modules.back();
|
2010-08-10 05:09:46 +08:00
|
|
|
|
2009-02-03 15:13:24 +08:00
|
|
|
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 09:46:41 +08: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->getModule().getSourceFileName()).str();
|
2009-02-03 15:13:24 +08:00
|
|
|
|
2015-10-04 22:33:43 +08:00
|
|
|
// If we are doing ThinLTO compilation, don't need to process the symbols.
|
|
|
|
// Later we simply build a combined index file after all files are claimed.
|
2016-03-05 01:06:02 +08:00
|
|
|
if (options::thinlto && options::thinlto_index_only)
|
2015-11-03 02:02:11 +08:00
|
|
|
return LDPS_OK;
|
2015-10-04 22:33:43 +08:00
|
|
|
|
2014-08-22 04:28:55 +08:00
|
|
|
for (auto &Sym : Obj->symbols()) {
|
|
|
|
uint32_t Symflags = Sym.getFlags();
|
2014-12-10 00:13:59 +08:00
|
|
|
if (shouldSkip(Symflags))
|
2009-02-03 15:13:24 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
cf.syms.push_back(ld_plugin_symbol());
|
|
|
|
ld_plugin_symbol &sym = cf.syms.back();
|
2014-07-30 05:46:05 +08:00
|
|
|
sym.version = nullptr;
|
2009-02-03 15:13:24 +08:00
|
|
|
|
2014-08-22 04:28:55 +08:00
|
|
|
SmallString<64> Name;
|
|
|
|
{
|
|
|
|
raw_svector_ostream OS(Name);
|
|
|
|
Sym.printName(OS);
|
|
|
|
}
|
|
|
|
sym.name = strdup(Name.c_str());
|
|
|
|
|
|
|
|
const GlobalValue *GV = Obj->getSymbolGV(Sym.getRawDataRefImpl());
|
|
|
|
|
2015-12-10 22:19:35 +08:00
|
|
|
ResolutionInfo &Res = ResInfo[sym.name];
|
|
|
|
|
2014-08-22 04:28:55 +08:00
|
|
|
sym.visibility = LDPV_DEFAULT;
|
|
|
|
if (GV) {
|
2015-12-10 22:19:35 +08:00
|
|
|
Res.UnnamedAddr &= GV->hasUnnamedAddr();
|
|
|
|
Res.IsLinkonceOdr &= GV->hasLinkOnceLinkage();
|
|
|
|
Res.Visibility = getMinVisibility(Res.Visibility, GV->getVisibility());
|
2014-08-22 04:28:55 +08:00
|
|
|
switch (GV->getVisibility()) {
|
|
|
|
case GlobalValue::DefaultVisibility:
|
|
|
|
break;
|
|
|
|
case GlobalValue::HiddenVisibility:
|
2009-02-03 15:13:24 +08:00
|
|
|
sym.visibility = LDPV_HIDDEN;
|
|
|
|
break;
|
2014-08-22 04:28:55 +08:00
|
|
|
case GlobalValue::ProtectedVisibility:
|
2009-02-03 15:13:24 +08:00
|
|
|
sym.visibility = LDPV_PROTECTED;
|
|
|
|
break;
|
2014-08-22 04:28:55 +08:00
|
|
|
}
|
2009-02-03 15:13:24 +08:00
|
|
|
}
|
|
|
|
|
2014-08-22 04:28:55 +08:00
|
|
|
if (Symflags & object::BasicSymbolRef::SF_Undefined) {
|
|
|
|
sym.def = LDPK_UNDEF;
|
|
|
|
if (GV && GV->hasExternalWeakLinkage())
|
2009-04-25 00:55:21 +08:00
|
|
|
sym.def = LDPK_WEAKUNDEF;
|
2014-08-22 04:28:55 +08:00
|
|
|
} else {
|
|
|
|
sym.def = LDPK_DEF;
|
|
|
|
if (GV) {
|
|
|
|
assert(!GV->hasExternalWeakLinkage() &&
|
|
|
|
!GV->hasAvailableExternallyLinkage() && "Not a declaration!");
|
|
|
|
if (GV->hasCommonLinkage())
|
|
|
|
sym.def = LDPK_COMMON;
|
|
|
|
else if (GV->isWeakForLinker())
|
|
|
|
sym.def = LDPK_WEAKDEF;
|
|
|
|
}
|
2009-02-03 15:13:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
sym.size = 0;
|
2014-08-22 04:28:55 +08:00
|
|
|
sym.comdat_key = nullptr;
|
2014-08-23 07:26:10 +08:00
|
|
|
if (GV) {
|
|
|
|
const GlobalObject *Base = getBaseObject(*GV);
|
|
|
|
if (!Base)
|
|
|
|
message(LDPL_FATAL, "Unable to determine comdat of alias!");
|
|
|
|
const Comdat *C = Base->getComdat();
|
|
|
|
if (C)
|
|
|
|
sym.comdat_key = strdup(C->getName().str().c_str());
|
|
|
|
}
|
2009-02-03 15:13:24 +08:00
|
|
|
|
|
|
|
sym.resolution = LDPR_UNKNOWN;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!cf.syms.empty()) {
|
2015-08-06 05:16:02 +08:00
|
|
|
if (add_symbols(cf.handle, cf.syms.size(), cf.syms.data()) != LDPS_OK) {
|
2014-07-30 08:38:58 +08:00
|
|
|
message(LDPL_ERROR, "Unable to add symbols!");
|
2009-02-03 15:13:24 +08:00
|
|
|
return LDPS_ERR;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-08-22 04:28:55 +08:00
|
|
|
return LDPS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void internalize(GlobalValue &GV) {
|
2014-10-25 02:13:04 +08:00
|
|
|
if (GV.isDeclarationForLinker())
|
2014-08-22 04:28:55 +08:00
|
|
|
return; // We get here if there is a matching asm definition.
|
|
|
|
if (!GV.hasLocalLinkage())
|
|
|
|
GV.setLinkage(GlobalValue::InternalLinkage);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const char *getResolutionName(ld_plugin_symbol_resolution R) {
|
|
|
|
switch (R) {
|
|
|
|
case LDPR_UNKNOWN:
|
|
|
|
return "UNKNOWN";
|
|
|
|
case LDPR_UNDEF:
|
|
|
|
return "UNDEF";
|
|
|
|
case LDPR_PREVAILING_DEF:
|
|
|
|
return "PREVAILING_DEF";
|
|
|
|
case LDPR_PREVAILING_DEF_IRONLY:
|
|
|
|
return "PREVAILING_DEF_IRONLY";
|
|
|
|
case LDPR_PREEMPTED_REG:
|
|
|
|
return "PREEMPTED_REG";
|
|
|
|
case LDPR_PREEMPTED_IR:
|
|
|
|
return "PREEMPTED_IR";
|
|
|
|
case LDPR_RESOLVED_IR:
|
|
|
|
return "RESOLVED_IR";
|
|
|
|
case LDPR_RESOLVED_EXEC:
|
|
|
|
return "RESOLVED_EXEC";
|
|
|
|
case LDPR_RESOLVED_DYN:
|
|
|
|
return "RESOLVED_DYN";
|
|
|
|
case LDPR_PREVAILING_DEF_IRONLY_EXP:
|
|
|
|
return "PREVAILING_DEF_IRONLY_EXP";
|
|
|
|
}
|
2014-10-10 08:48:13 +08:00
|
|
|
llvm_unreachable("Unknown resolution");
|
2014-08-22 04:28:55 +08:00
|
|
|
}
|
|
|
|
|
2014-12-24 02:18:37 +08:00
|
|
|
static void freeSymName(ld_plugin_symbol &Sym) {
|
|
|
|
free(Sym.name);
|
|
|
|
free(Sym.comdat_key);
|
|
|
|
Sym.name = nullptr;
|
|
|
|
Sym.comdat_key = nullptr;
|
|
|
|
}
|
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
/// Helper to get a file's symbols and a view into it via gold callbacks.
|
|
|
|
static const void *getSymbolsAndView(claimed_file &F) {
|
2016-03-08 22:02:46 +08:00
|
|
|
ld_plugin_status status = get_symbols(F.handle, F.syms.size(), F.syms.data());
|
2016-03-04 08:23:29 +08:00
|
|
|
if (status == LDPS_NO_SYMS)
|
|
|
|
return nullptr;
|
2015-10-04 22:33:43 +08:00
|
|
|
|
2016-03-04 08:23:29 +08:00
|
|
|
if (status != LDPS_OK)
|
2015-10-04 22:33:43 +08:00
|
|
|
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");
|
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
return View;
|
|
|
|
}
|
|
|
|
|
2016-03-15 08:04:37 +08:00
|
|
|
static std::unique_ptr<ModuleSummaryIndex>
|
[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 09:46:41 +08:00
|
|
|
getModuleSummaryIndexForFile(claimed_file &F) {
|
2016-03-05 00:36:06 +08:00
|
|
|
const void *View = getSymbolsAndView(F);
|
2016-03-11 08:51:57 +08:00
|
|
|
if (!View)
|
|
|
|
return nullptr;
|
2016-03-05 00:36:06 +08:00
|
|
|
|
[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 09:46:41 +08:00
|
|
|
MemoryBufferRef BufferRef(StringRef((const char *)View, F.filesize), F.name);
|
2015-11-22 05:55:48 +08:00
|
|
|
|
|
|
|
// Don't bother trying to build an index if there is no summary information
|
|
|
|
// in this bitcode file.
|
2016-03-15 08:04:37 +08:00
|
|
|
if (!object::ModuleSummaryIndexObjectFile::hasGlobalValueSummaryInMemBuffer(
|
2015-11-22 05:55:48 +08:00
|
|
|
BufferRef, diagnosticHandler))
|
2016-03-15 08:04:37 +08:00
|
|
|
return std::unique_ptr<ModuleSummaryIndex>(nullptr);
|
2015-11-22 05:55:48 +08:00
|
|
|
|
2016-03-15 08:04:37 +08:00
|
|
|
ErrorOr<std::unique_ptr<object::ModuleSummaryIndexObjectFile>> ObjOrErr =
|
|
|
|
object::ModuleSummaryIndexObjectFile::create(BufferRef,
|
|
|
|
diagnosticHandler);
|
2015-10-04 22:33:43 +08:00
|
|
|
|
|
|
|
if (std::error_code EC = ObjOrErr.getError())
|
2016-03-15 08:04:37 +08:00
|
|
|
message(LDPL_FATAL,
|
|
|
|
"Could not read module summary index bitcode from file : %s",
|
2015-10-04 22:33:43 +08:00
|
|
|
EC.message().c_str());
|
|
|
|
|
2016-03-15 08:04:37 +08:00
|
|
|
object::ModuleSummaryIndexObjectFile &Obj = **ObjOrErr;
|
2015-10-04 22:33:43 +08:00
|
|
|
|
|
|
|
return Obj.takeIndex();
|
|
|
|
}
|
|
|
|
|
[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 09:46:41 +08:00
|
|
|
static std::unique_ptr<Module> getModuleForFile(
|
|
|
|
LLVMContext &Context, claimed_file &F, const void *View, StringRef Name,
|
|
|
|
raw_fd_ostream *ApiFile, StringSet<> &Internalize, StringSet<> &Maybe,
|
|
|
|
std::vector<GlobalValue *> &Keep, StringMap<unsigned> &Realign) {
|
|
|
|
MemoryBufferRef BufferRef(StringRef((const char *)View, F.filesize), Name);
|
2014-12-10 00:13:59 +08:00
|
|
|
ErrorOr<std::unique_ptr<object::IRObjectFile>> ObjOrErr =
|
2014-12-10 04:36:13 +08:00
|
|
|
object::IRObjectFile::create(BufferRef, Context);
|
2014-12-10 00:13:59 +08:00
|
|
|
|
|
|
|
if (std::error_code EC = ObjOrErr.getError())
|
2014-09-19 05:28:49 +08:00
|
|
|
message(LDPL_FATAL, "Could not read bitcode from file : %s",
|
|
|
|
EC.message().c_str());
|
|
|
|
|
2014-12-10 00:13:59 +08:00
|
|
|
object::IRObjectFile &Obj = **ObjOrErr;
|
2014-08-22 04:28:55 +08:00
|
|
|
|
2014-12-10 00:13:59 +08:00
|
|
|
Module &M = Obj.getModule();
|
2014-08-22 04:28:55 +08:00
|
|
|
|
2015-03-31 05:36:43 +08:00
|
|
|
M.materializeMetadata();
|
|
|
|
UpgradeDebugInfo(M);
|
2015-03-03 03:08:03 +08:00
|
|
|
|
2014-08-22 04:28:55 +08:00
|
|
|
SmallPtrSet<GlobalValue *, 8> Used;
|
2014-12-10 00:13:59 +08:00
|
|
|
collectUsedGlobalVariables(M, Used, /*CompilerUsed*/ false);
|
2014-08-22 04:28:55 +08:00
|
|
|
|
2014-12-10 00:13:59 +08:00
|
|
|
unsigned SymNum = 0;
|
|
|
|
for (auto &ObjSym : Obj.symbols()) {
|
2015-12-10 22:19:35 +08:00
|
|
|
GlobalValue *GV = Obj.getSymbolGV(ObjSym.getRawDataRefImpl());
|
|
|
|
if (GV && GV->hasAppendingLinkage())
|
|
|
|
Keep.push_back(GV);
|
|
|
|
|
2014-12-10 00:13:59 +08:00
|
|
|
if (shouldSkip(ObjSym.getFlags()))
|
|
|
|
continue;
|
|
|
|
ld_plugin_symbol &Sym = F.syms[SymNum];
|
|
|
|
++SymNum;
|
|
|
|
|
2014-08-22 04:28:55 +08:00
|
|
|
ld_plugin_symbol_resolution Resolution =
|
|
|
|
(ld_plugin_symbol_resolution)Sym.resolution;
|
|
|
|
|
|
|
|
if (options::generate_api_file)
|
|
|
|
*ApiFile << Sym.name << ' ' << getResolutionName(Resolution) << '\n';
|
|
|
|
|
2014-12-24 02:18:37 +08:00
|
|
|
if (!GV) {
|
|
|
|
freeSymName(Sym);
|
2014-08-22 04:28:55 +08:00
|
|
|
continue; // Asm symbol.
|
2014-12-24 02:18:37 +08:00
|
|
|
}
|
2014-08-22 04:28:55 +08:00
|
|
|
|
2015-12-10 22:19:35 +08:00
|
|
|
ResolutionInfo &Res = ResInfo[Sym.name];
|
|
|
|
if (Resolution == LDPR_PREVAILING_DEF_IRONLY_EXP && !Res.IsLinkonceOdr)
|
|
|
|
Resolution = LDPR_PREVAILING_DEF;
|
|
|
|
|
2016-03-05 01:48:35 +08:00
|
|
|
// In ThinLTO mode change all prevailing resolutions to LDPR_PREVAILING_DEF.
|
|
|
|
// For ThinLTO the IR files are compiled through the backend independently,
|
|
|
|
// so we need to ensure that any prevailing linkonce copy will be emitted
|
|
|
|
// into the object file by making it weak. Additionally, we can skip the
|
|
|
|
// IRONLY handling for internalization, which isn't performed in ThinLTO
|
|
|
|
// mode currently anyway.
|
|
|
|
if (options::thinlto && (Resolution == LDPR_PREVAILING_DEF_IRONLY_EXP ||
|
|
|
|
Resolution == LDPR_PREVAILING_DEF_IRONLY))
|
|
|
|
Resolution = LDPR_PREVAILING_DEF;
|
|
|
|
|
2015-12-10 22:19:35 +08:00
|
|
|
GV->setUnnamedAddr(Res.UnnamedAddr);
|
|
|
|
GV->setVisibility(Res.Visibility);
|
|
|
|
|
|
|
|
// Override gold's resolution for common symbols. We want the largest
|
|
|
|
// one to win.
|
|
|
|
if (GV->hasCommonLinkage()) {
|
|
|
|
if (Resolution == LDPR_PREVAILING_DEF_IRONLY)
|
|
|
|
Res.CommonInternal = true;
|
|
|
|
|
|
|
|
if (Resolution == LDPR_PREVAILING_DEF_IRONLY ||
|
|
|
|
Resolution == LDPR_PREVAILING_DEF)
|
|
|
|
Res.UseCommon = true;
|
|
|
|
|
2016-03-11 08:51:57 +08:00
|
|
|
const DataLayout &DL = GV->getParent()->getDataLayout();
|
|
|
|
uint64_t Size = DL.getTypeAllocSize(GV->getType()->getElementType());
|
|
|
|
unsigned Align = GV->getAlignment();
|
|
|
|
|
|
|
|
if (Res.UseCommon && Size >= Res.CommonSize) {
|
|
|
|
// Take GV.
|
2015-12-10 22:19:35 +08:00
|
|
|
if (Res.CommonInternal)
|
|
|
|
Resolution = LDPR_PREVAILING_DEF_IRONLY;
|
|
|
|
else
|
|
|
|
Resolution = LDPR_PREVAILING_DEF;
|
2016-03-11 08:51:57 +08:00
|
|
|
cast<GlobalVariable>(GV)->setAlignment(
|
|
|
|
std::max(Res.CommonAlign, Align));
|
2015-12-10 22:19:35 +08:00
|
|
|
} else {
|
2016-03-11 08:51:57 +08:00
|
|
|
// Do not take GV, it's smaller than what we already have in the
|
|
|
|
// combined module.
|
2015-12-10 22:19:35 +08:00
|
|
|
Resolution = LDPR_PREEMPTED_IR;
|
2016-03-11 08:51:57 +08:00
|
|
|
if (Align > Res.CommonAlign)
|
|
|
|
// Need to raise the alignment though.
|
|
|
|
Realign[Sym.name] = Align;
|
2015-12-10 22:19:35 +08:00
|
|
|
}
|
2016-03-11 08:51:57 +08:00
|
|
|
|
|
|
|
Res.CommonSize = std::max(Res.CommonSize, Size);
|
|
|
|
Res.CommonAlign = std::max(Res.CommonAlign, Align);
|
2014-09-10 04:08:22 +08:00
|
|
|
}
|
|
|
|
|
2014-08-22 04:28:55 +08:00
|
|
|
switch (Resolution) {
|
|
|
|
case LDPR_UNKNOWN:
|
|
|
|
llvm_unreachable("Unexpected resolution");
|
|
|
|
|
|
|
|
case LDPR_RESOLVED_IR:
|
|
|
|
case LDPR_RESOLVED_EXEC:
|
|
|
|
case LDPR_RESOLVED_DYN:
|
2015-12-10 22:19:35 +08:00
|
|
|
case LDPR_PREEMPTED_IR:
|
|
|
|
case LDPR_PREEMPTED_REG:
|
2014-08-22 04:28:55 +08:00
|
|
|
break;
|
|
|
|
|
2015-01-14 21:53:50 +08:00
|
|
|
case LDPR_UNDEF:
|
2015-12-10 22:19:35 +08:00
|
|
|
if (!GV->isDeclarationForLinker())
|
2015-01-15 03:43:32 +08:00
|
|
|
assert(GV->hasComdat());
|
2015-01-14 21:53:50 +08:00
|
|
|
break;
|
|
|
|
|
2014-08-22 04:28:55 +08:00
|
|
|
case LDPR_PREVAILING_DEF_IRONLY: {
|
2015-12-10 22:19:35 +08:00
|
|
|
Keep.push_back(GV);
|
|
|
|
// The IR linker has to be able to map this value to a declaration,
|
|
|
|
// so we can only internalize after linking.
|
|
|
|
if (!Used.count(GV))
|
2014-12-10 00:50:57 +08:00
|
|
|
Internalize.insert(GV->getName());
|
2014-08-22 04:28:55 +08:00
|
|
|
break;
|
2013-10-19 03:32:06 +08:00
|
|
|
}
|
2014-08-22 04:28:55 +08:00
|
|
|
|
|
|
|
case LDPR_PREVAILING_DEF:
|
2015-12-10 22:19:35 +08:00
|
|
|
Keep.push_back(GV);
|
|
|
|
// There is a non IR use, so we have to force optimizations to keep this.
|
|
|
|
switch (GV->getLinkage()) {
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
case GlobalValue::LinkOnceAnyLinkage:
|
|
|
|
GV->setLinkage(GlobalValue::WeakAnyLinkage);
|
|
|
|
break;
|
|
|
|
case GlobalValue::LinkOnceODRLinkage:
|
|
|
|
GV->setLinkage(GlobalValue::WeakODRLinkage);
|
|
|
|
break;
|
|
|
|
}
|
2014-08-22 04:28:55 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case LDPR_PREVAILING_DEF_IRONLY_EXP: {
|
|
|
|
// We can only check for address uses after we merge the modules. The
|
|
|
|
// reason is that this GV might have a copy in another module
|
|
|
|
// and in that module the address might be significant, but that
|
|
|
|
// copy will be LDPR_PREEMPTED_IR.
|
2015-12-10 22:19:35 +08:00
|
|
|
Maybe.insert(GV->getName());
|
|
|
|
Keep.push_back(GV);
|
2014-08-22 04:28:55 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-12-24 02:18:37 +08:00
|
|
|
freeSymName(Sym);
|
2013-10-19 03:32:06 +08:00
|
|
|
}
|
2011-02-21 02:28:29 +08:00
|
|
|
|
2014-12-10 00:13:59 +08:00
|
|
|
return Obj.takeModule();
|
2009-02-03 15:13:24 +08:00
|
|
|
}
|
|
|
|
|
2015-04-15 08:13:51 +08:00
|
|
|
static void saveBCFile(StringRef Path, Module &M) {
|
2014-10-30 07:54:45 +08:00
|
|
|
std::error_code EC;
|
|
|
|
raw_fd_ostream OS(Path, EC, sys::fs::OpenFlags::F_None);
|
|
|
|
if (EC)
|
|
|
|
message(LDPL_FATAL, "Failed to write the output file.");
|
2015-12-23 07:45:49 +08:00
|
|
|
WriteBitcodeToFile(&M, OS, /* ShouldPreserveUseListOrder */ false);
|
2014-10-30 07:54:45 +08:00
|
|
|
}
|
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
static void recordFile(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.c_str());
|
|
|
|
}
|
2014-08-22 04:28:55 +08:00
|
|
|
|
2016-03-05 01:06:02 +08:00
|
|
|
void ThinLTOTaskInfo::cleanup() {
|
|
|
|
// Close the output file descriptor before we pass it to gold.
|
|
|
|
OS->close();
|
|
|
|
|
|
|
|
recordFile(Filename, TempOutFile);
|
|
|
|
}
|
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
namespace {
|
2016-03-05 01:06:02 +08:00
|
|
|
/// Class to manage optimization and code generation for a module, possibly
|
|
|
|
/// in a thread (ThinLTO).
|
2016-03-05 00:36:06 +08:00
|
|
|
class CodeGen {
|
|
|
|
/// The module for which this will generate code.
|
|
|
|
std::unique_ptr<llvm::Module> M;
|
|
|
|
|
2016-03-05 01:06:02 +08:00
|
|
|
/// The output stream to generate code into.
|
|
|
|
raw_fd_ostream *OS;
|
|
|
|
|
|
|
|
/// The task ID when this was invoked in a thread (ThinLTO).
|
|
|
|
int TaskID;
|
|
|
|
|
2016-03-15 08:04:37 +08:00
|
|
|
/// The module summary index for ThinLTO tasks.
|
|
|
|
const ModuleSummaryIndex *CombinedIndex;
|
2016-03-05 01:06:02 +08:00
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
/// The target machine for generating code for this module.
|
|
|
|
std::unique_ptr<TargetMachine> TM;
|
|
|
|
|
2016-03-05 01:06:02 +08:00
|
|
|
/// Filename to use as base when save-temps is enabled, used to get
|
|
|
|
/// a unique and identifiable save-temps output file for each ThinLTO backend.
|
|
|
|
std::string SaveTempsFilename;
|
|
|
|
|
[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 09:46:41 +08:00
|
|
|
/// Map from a module name to the corresponding buffer holding a view of the
|
|
|
|
/// bitcode provided via the get_view gold callback.
|
|
|
|
StringMap<MemoryBufferRef> *ModuleMap;
|
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
public:
|
|
|
|
/// Constructor used by full LTO.
|
2016-03-05 01:06:02 +08:00
|
|
|
CodeGen(std::unique_ptr<llvm::Module> M)
|
[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 09:46:41 +08:00
|
|
|
: M(std::move(M)), OS(nullptr), TaskID(-1), CombinedIndex(nullptr),
|
|
|
|
ModuleMap(nullptr) {
|
2016-03-05 01:06:02 +08:00
|
|
|
initTargetMachine();
|
|
|
|
}
|
|
|
|
/// Constructor used by ThinLTO.
|
|
|
|
CodeGen(std::unique_ptr<llvm::Module> M, raw_fd_ostream *OS, int TaskID,
|
[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 09:46:41 +08:00
|
|
|
const ModuleSummaryIndex *CombinedIndex, std::string Filename,
|
|
|
|
StringMap<MemoryBufferRef> *ModuleMap)
|
2016-03-05 01:06:02 +08:00
|
|
|
: M(std::move(M)), OS(OS), TaskID(TaskID), CombinedIndex(CombinedIndex),
|
[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 09:46:41 +08:00
|
|
|
SaveTempsFilename(Filename), ModuleMap(ModuleMap) {
|
2016-03-05 01:06:02 +08:00
|
|
|
assert(options::thinlto == !!CombinedIndex &&
|
2016-03-15 08:04:37 +08:00
|
|
|
"Expected module summary index iff performing ThinLTO");
|
2016-03-05 00:36:06 +08:00
|
|
|
initTargetMachine();
|
|
|
|
}
|
2014-08-22 04:28:55 +08:00
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
/// Invoke LTO passes and the code generator for the module.
|
|
|
|
void runAll();
|
|
|
|
|
2016-03-05 01:06:02 +08:00
|
|
|
/// Invoke the actual code generation to emit Module's object to file.
|
|
|
|
void runCodegenPasses();
|
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
private:
|
2016-04-18 02:42:27 +08:00
|
|
|
const Target *TheTarget;
|
2016-04-18 02:56:49 +08:00
|
|
|
std::string TripleStr;
|
2016-04-18 02:42:27 +08:00
|
|
|
std::string FeaturesString;
|
|
|
|
TargetOptions Options;
|
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
/// Create a target machine for the module. Must be unique for each
|
|
|
|
/// module/task.
|
|
|
|
void initTargetMachine();
|
|
|
|
|
2016-04-18 02:42:27 +08:00
|
|
|
std::unique_ptr<TargetMachine> createTargetMachine();
|
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
/// Run all LTO passes on the module.
|
|
|
|
void runLTOPasses();
|
|
|
|
|
|
|
|
/// Sets up output files necessary to perform optional multi-threaded
|
|
|
|
/// split code generation, and invokes the code generation implementation.
|
2016-04-07 02:32:13 +08:00
|
|
|
/// If BCFileName is not empty, saves bitcode for module partitions into
|
|
|
|
/// {BCFileName}0 .. {BCFileName}N.
|
|
|
|
void runSplitCodeGen(const SmallString<128> &BCFilename);
|
2016-03-05 00:36:06 +08:00
|
|
|
};
|
|
|
|
}
|
2014-08-22 04:28:55 +08:00
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
static SubtargetFeatures getFeatures(Triple &TheTriple) {
|
2014-08-22 04:28:55 +08:00
|
|
|
SubtargetFeatures Features;
|
|
|
|
Features.getDefaultSubtargetFeatures(TheTriple);
|
|
|
|
for (const std::string &A : MAttrs)
|
|
|
|
Features.AddFeature(A);
|
2016-03-05 00:36:06 +08:00
|
|
|
return Features;
|
|
|
|
}
|
2014-08-22 04:28:55 +08:00
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
static CodeGenOpt::Level getCGOptLevel() {
|
2015-03-20 06:01:00 +08:00
|
|
|
switch (options::OptLevel) {
|
|
|
|
case 0:
|
2016-03-19 10:34:33 +08:00
|
|
|
return CodeGenOpt::None;
|
2015-03-20 06:01:00 +08:00
|
|
|
case 1:
|
2016-03-19 10:34:33 +08:00
|
|
|
return CodeGenOpt::Less;
|
2015-03-20 06:01:00 +08:00
|
|
|
case 2:
|
2016-03-19 10:34:33 +08:00
|
|
|
return CodeGenOpt::Default;
|
2015-03-20 06:01:00 +08:00
|
|
|
case 3:
|
2016-03-19 10:34:33 +08:00
|
|
|
return CodeGenOpt::Aggressive;
|
2015-03-20 06:01:00 +08:00
|
|
|
}
|
2016-03-19 10:34:33 +08:00
|
|
|
llvm_unreachable("Invalid optimization level");
|
2016-03-05 00:36:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void CodeGen::initTargetMachine() {
|
2016-04-18 02:56:49 +08:00
|
|
|
TripleStr = M->getTargetTriple();
|
2016-03-05 00:36:06 +08:00
|
|
|
Triple TheTriple(TripleStr);
|
|
|
|
|
|
|
|
std::string ErrMsg;
|
2016-04-18 02:42:27 +08:00
|
|
|
TheTarget = TargetRegistry::lookupTarget(TripleStr, ErrMsg);
|
2016-03-05 00:36:06 +08:00
|
|
|
if (!TheTarget)
|
|
|
|
message(LDPL_FATAL, "Target not found: %s", ErrMsg.c_str());
|
|
|
|
|
|
|
|
SubtargetFeatures Features = getFeatures(TheTriple);
|
2016-04-18 02:42:27 +08:00
|
|
|
FeaturesString = Features.getString();
|
|
|
|
Options = InitTargetOptionsFromCodeGenFlags();
|
|
|
|
|
|
|
|
TM = createTargetMachine();
|
|
|
|
}
|
|
|
|
|
|
|
|
std::unique_ptr<TargetMachine> CodeGen::createTargetMachine() {
|
2016-03-05 00:36:06 +08:00
|
|
|
CodeGenOpt::Level CGOptLevel = getCGOptLevel();
|
|
|
|
|
2016-04-18 02:42:27 +08:00
|
|
|
return std::unique_ptr<TargetMachine>(TheTarget->createTargetMachine(
|
|
|
|
TripleStr, options::mcpu, FeaturesString, Options, RelocationModel,
|
2015-03-20 06:01:00 +08:00
|
|
|
CodeModel::Default, CGOptLevel));
|
2016-03-05 00:36:06 +08:00
|
|
|
}
|
2014-08-22 04:28:55 +08:00
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
void CodeGen::runLTOPasses() {
|
|
|
|
M->setDataLayout(TM->createDataLayout());
|
2014-08-22 04:28:55 +08:00
|
|
|
|
[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 09:46:41 +08:00
|
|
|
if (CombinedIndex) {
|
|
|
|
// First collect the import list.
|
|
|
|
FunctionImporter::ImportMapTy ImportList;
|
|
|
|
ComputeCrossModuleImportForModule(M->getModuleIdentifier(), *CombinedIndex,
|
|
|
|
ImportList);
|
|
|
|
|
|
|
|
// Create a loader that will parse the bitcode from the buffers
|
|
|
|
// in the ModuleMap.
|
|
|
|
ModuleLoader Loader(M->getContext(), *ModuleMap);
|
|
|
|
|
|
|
|
// Perform function importing.
|
|
|
|
FunctionImporter Importer(*CombinedIndex, Loader);
|
|
|
|
Importer.importFunctions(*M, ImportList);
|
|
|
|
}
|
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
legacy::PassManager passes;
|
|
|
|
passes.add(createTargetTransformInfoWrapperPass(TM->getTargetIRAnalysis()));
|
|
|
|
|
|
|
|
PassManagerBuilder PMB;
|
|
|
|
PMB.LibraryInfo = new TargetLibraryInfoImpl(Triple(TM->getTargetTriple()));
|
|
|
|
PMB.Inliner = createFunctionInliningPass();
|
|
|
|
// Unconditionally verify input since it is not verified before this
|
|
|
|
// point and has unknown origin.
|
|
|
|
PMB.VerifyInput = true;
|
|
|
|
PMB.VerifyOutput = !options::DisableVerify;
|
|
|
|
PMB.LoopVectorize = true;
|
|
|
|
PMB.SLPVectorize = true;
|
|
|
|
PMB.OptLevel = options::OptLevel;
|
2016-05-13 09:25:31 +08:00
|
|
|
if (options::thinlto)
|
|
|
|
PMB.populateThinLTOPassManager(passes);
|
|
|
|
else
|
|
|
|
PMB.populateLTOPassManager(passes);
|
2016-03-05 00:36:06 +08:00
|
|
|
passes.run(*M);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Open a file and return the new file descriptor given a base input
|
|
|
|
/// file 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 openOutputFile(SmallString<128> InFilename, bool TempOutFile,
|
|
|
|
SmallString<128> &NewFilename, int TaskID = -1) {
|
|
|
|
int FD;
|
|
|
|
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", EC.message().c_str());
|
|
|
|
}
|
|
|
|
return FD;
|
|
|
|
}
|
|
|
|
|
2016-03-05 01:06:02 +08:00
|
|
|
void CodeGen::runCodegenPasses() {
|
|
|
|
assert(OS && "Output stream must be set before emitting to file");
|
|
|
|
legacy::PassManager CodeGenPasses;
|
|
|
|
if (TM->addPassesToEmitFile(CodeGenPasses, *OS,
|
|
|
|
TargetMachine::CGFT_ObjectFile))
|
|
|
|
report_fatal_error("Failed to setup codegen");
|
|
|
|
CodeGenPasses.run(*M);
|
|
|
|
}
|
|
|
|
|
2016-04-07 02:32:13 +08:00
|
|
|
void CodeGen::runSplitCodeGen(const SmallString<128> &BCFilename) {
|
2014-08-22 04:28:55 +08:00
|
|
|
SmallString<128> Filename;
|
2016-03-05 00:36:06 +08:00
|
|
|
// Note that openOutputFile will append a unique ID for each task
|
2015-06-15 21:36:27 +08:00
|
|
|
if (!options::obj_path.empty())
|
|
|
|
Filename = options::obj_path;
|
|
|
|
else if (options::TheOutputType == options::OT_SAVE_TEMPS)
|
|
|
|
Filename = output_name + ".o";
|
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
// Note that the default parallelism is 1 instead of the
|
|
|
|
// hardware_concurrency, as there are behavioral differences between
|
|
|
|
// parallelism levels (e.g. symbol ordering will be different, and some uses
|
|
|
|
// of inline asm currently have issues with parallelism >1).
|
|
|
|
unsigned int MaxThreads = options::Parallelism ? options::Parallelism : 1;
|
|
|
|
|
|
|
|
std::vector<SmallString<128>> Filenames(MaxThreads);
|
2016-04-07 02:32:13 +08:00
|
|
|
std::vector<SmallString<128>> BCFilenames(MaxThreads);
|
2015-06-15 21:36:27 +08:00
|
|
|
bool TempOutFile = Filename.empty();
|
2014-08-22 04:28:55 +08:00
|
|
|
{
|
2016-03-05 00:36:06 +08:00
|
|
|
// Open a file descriptor for each backend task. This is done in a block
|
2015-09-02 04:40:22 +08:00
|
|
|
// so that the output file descriptors are closed before gold opens them.
|
|
|
|
std::list<llvm::raw_fd_ostream> OSs;
|
2016-03-05 00:36:06 +08:00
|
|
|
std::vector<llvm::raw_pwrite_stream *> OSPtrs(MaxThreads);
|
|
|
|
for (unsigned I = 0; I != MaxThreads; ++I) {
|
2016-03-05 02:16:00 +08:00
|
|
|
int FD = openOutputFile(Filename, TempOutFile, Filenames[I],
|
|
|
|
// Only append ID if there are multiple tasks.
|
|
|
|
MaxThreads > 1 ? I : -1);
|
2015-09-02 04:40:22 +08:00
|
|
|
OSs.emplace_back(FD, true);
|
|
|
|
OSPtrs[I] = &OSs.back();
|
|
|
|
}
|
2014-08-22 04:28:55 +08:00
|
|
|
|
2016-04-07 02:32:13 +08:00
|
|
|
std::list<llvm::raw_fd_ostream> BCOSs;
|
|
|
|
std::vector<llvm::raw_pwrite_stream *> BCOSPtrs;
|
|
|
|
if (!BCFilename.empty() && MaxThreads > 1) {
|
|
|
|
for (unsigned I = 0; I != MaxThreads; ++I) {
|
|
|
|
int FD = openOutputFile(BCFilename, false, BCFilenames[I], I);
|
|
|
|
BCOSs.emplace_back(FD, true);
|
|
|
|
BCOSPtrs.push_back(&BCOSs.back());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
// Run backend tasks.
|
2016-04-18 02:42:27 +08:00
|
|
|
splitCodeGen(std::move(M), OSPtrs, BCOSPtrs,
|
|
|
|
[&]() { return createTargetMachine(); });
|
2014-08-22 04:28:55 +08:00
|
|
|
}
|
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
for (auto &Filename : Filenames)
|
|
|
|
recordFile(Filename.c_str(), TempOutFile);
|
|
|
|
}
|
|
|
|
|
|
|
|
void CodeGen::runAll() {
|
|
|
|
runLTOPasses();
|
|
|
|
|
2016-04-07 02:32:13 +08:00
|
|
|
SmallString<128> OptFilename;
|
2016-03-05 00:36:06 +08:00
|
|
|
if (options::TheOutputType == options::OT_SAVE_TEMPS) {
|
2016-04-07 02:32:13 +08:00
|
|
|
OptFilename = output_name;
|
2016-03-05 01:06:02 +08:00
|
|
|
// If the CodeGen client provided a filename, use it. Always expect
|
|
|
|
// a provided filename if we are in a task (i.e. ThinLTO backend).
|
|
|
|
assert(!SaveTempsFilename.empty() || TaskID == -1);
|
|
|
|
if (!SaveTempsFilename.empty())
|
|
|
|
OptFilename = SaveTempsFilename;
|
2016-04-07 02:32:13 +08:00
|
|
|
OptFilename += ".opt.bc";
|
|
|
|
saveBCFile(OptFilename, *M);
|
2015-09-02 04:40:22 +08:00
|
|
|
}
|
2016-03-05 00:36:06 +08:00
|
|
|
|
2016-03-05 01:06:02 +08:00
|
|
|
// If we are already in a thread (i.e. ThinLTO), just perform
|
|
|
|
// codegen passes directly.
|
|
|
|
if (TaskID >= 0)
|
|
|
|
runCodegenPasses();
|
|
|
|
// Otherwise attempt split code gen.
|
|
|
|
else
|
2016-04-07 02:32:13 +08:00
|
|
|
runSplitCodeGen(OptFilename);
|
2016-03-05 00:36:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Links the module in \p View from file \p F into the combined module
|
2016-05-27 13:21:35 +08:00
|
|
|
/// saved in the IRMover \p L.
|
|
|
|
static void linkInModule(LLVMContext &Context, IRMover &L, claimed_file &F,
|
[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 09:46:41 +08:00
|
|
|
const void *View, StringRef Name,
|
2016-03-05 00:36:06 +08:00
|
|
|
raw_fd_ostream *ApiFile, StringSet<> &Internalize,
|
|
|
|
StringSet<> &Maybe) {
|
|
|
|
std::vector<GlobalValue *> Keep;
|
2016-03-11 08:51:57 +08:00
|
|
|
StringMap<unsigned> Realign;
|
|
|
|
std::unique_ptr<Module> M = getModuleForFile(
|
[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 09:46:41 +08:00
|
|
|
Context, F, View, Name, ApiFile, Internalize, Maybe, Keep, Realign);
|
2016-03-05 00:36:06 +08:00
|
|
|
if (!M.get())
|
2016-05-27 13:21:35 +08:00
|
|
|
return;
|
2016-03-05 00:36:06 +08:00
|
|
|
if (!options::triple.empty())
|
|
|
|
M->setTargetTriple(options::triple.c_str());
|
|
|
|
else if (M->getTargetTriple().empty()) {
|
|
|
|
M->setTargetTriple(DefaultTriple);
|
|
|
|
}
|
|
|
|
|
2016-05-27 13:21:35 +08:00
|
|
|
if (Error E = L.move(std::move(M), Keep,
|
|
|
|
[](GlobalValue &, IRMover::ValueAdder) {})) {
|
|
|
|
handleAllErrors(std::move(E), [&](const llvm::ErrorInfoBase &EIB) {
|
|
|
|
message(LDPL_FATAL, "Failed to link module %s: %s", Name.str().c_str(),
|
|
|
|
EIB.message().c_str());
|
|
|
|
});
|
|
|
|
}
|
2016-03-11 08:51:57 +08:00
|
|
|
|
|
|
|
for (const auto &I : Realign) {
|
|
|
|
GlobalValue *Dst = L.getModule().getNamedValue(I.first());
|
|
|
|
if (!Dst)
|
|
|
|
continue;
|
|
|
|
cast<GlobalVariable>(Dst)->setAlignment(I.second);
|
|
|
|
}
|
2013-11-01 04:51:58 +08:00
|
|
|
}
|
|
|
|
|
2016-03-05 01:06:02 +08:00
|
|
|
/// Perform the ThinLTO backend on a single module, invoking the LTO and codegen
|
|
|
|
/// pipelines.
|
|
|
|
static void thinLTOBackendTask(claimed_file &F, const void *View,
|
[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 09:46:41 +08:00
|
|
|
StringRef Name, raw_fd_ostream *ApiFile,
|
2016-03-15 08:04:37 +08:00
|
|
|
const ModuleSummaryIndex &CombinedIndex,
|
[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 09:46:41 +08:00
|
|
|
raw_fd_ostream *OS, unsigned TaskID,
|
|
|
|
StringMap<MemoryBufferRef> &ModuleMap) {
|
2016-03-05 01:06:02 +08:00
|
|
|
// Need to use a separate context for each task
|
|
|
|
LLVMContext Context;
|
2016-04-23 13:15:59 +08:00
|
|
|
Context.setDiscardValueNames(options::TheOutputType !=
|
|
|
|
options::OT_SAVE_TEMPS);
|
2016-04-19 12:55:25 +08:00
|
|
|
Context.enableDebugTypeODRUniquing(); // Merge debug info types.
|
2016-03-05 01:06:02 +08:00
|
|
|
Context.setDiagnosticHandler(diagnosticHandlerForContext, nullptr, true);
|
|
|
|
|
[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 09:46:41 +08:00
|
|
|
std::unique_ptr<llvm::Module> NewModule(new llvm::Module(Name, Context));
|
2016-03-05 01:06:02 +08:00
|
|
|
IRMover L(*NewModule.get());
|
|
|
|
|
|
|
|
StringSet<> Dummy;
|
2016-05-27 13:21:35 +08:00
|
|
|
linkInModule(Context, L, F, View, Name, ApiFile, Dummy, Dummy);
|
2016-03-09 09:55:15 +08:00
|
|
|
if (renameModuleForThinLTO(*NewModule, CombinedIndex))
|
2016-03-05 01:06:02 +08:00
|
|
|
message(LDPL_FATAL, "Failed to rename module for ThinLTO");
|
|
|
|
|
[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 09:46:41 +08:00
|
|
|
CodeGen codeGen(std::move(NewModule), OS, TaskID, &CombinedIndex, Name,
|
|
|
|
&ModuleMap);
|
2016-03-05 01:06:02 +08:00
|
|
|
codeGen.runAll();
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Launch each module's backend pipeline in a separate task in a thread pool.
|
|
|
|
static void thinLTOBackends(raw_fd_ostream *ApiFile,
|
[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 09:46:41 +08:00
|
|
|
const ModuleSummaryIndex &CombinedIndex,
|
|
|
|
StringMap<MemoryBufferRef> &ModuleMap) {
|
2016-03-05 01:06:02 +08:00
|
|
|
unsigned TaskCount = 0;
|
|
|
|
std::vector<ThinLTOTaskInfo> Tasks;
|
|
|
|
Tasks.reserve(Modules.size());
|
|
|
|
unsigned int MaxThreads = options::Parallelism
|
|
|
|
? options::Parallelism
|
|
|
|
: thread::hardware_concurrency();
|
|
|
|
|
|
|
|
// Create ThreadPool in nested scope so that threads will be joined
|
|
|
|
// on destruction.
|
|
|
|
{
|
|
|
|
ThreadPool ThinLTOThreadPool(MaxThreads);
|
|
|
|
for (claimed_file &F : Modules) {
|
|
|
|
// Do all the gold callbacks in the main thread, since gold is not thread
|
|
|
|
// safe by default.
|
|
|
|
const void *View = getSymbolsAndView(F);
|
2016-03-11 08:51:57 +08:00
|
|
|
if (!View)
|
|
|
|
continue;
|
2016-03-05 01:06:02 +08:00
|
|
|
|
|
|
|
SmallString<128> Filename;
|
|
|
|
if (!options::obj_path.empty())
|
|
|
|
// Note that openOutputFile will append a unique ID for each task
|
|
|
|
Filename = options::obj_path;
|
|
|
|
else if (options::TheOutputType == options::OT_SAVE_TEMPS) {
|
|
|
|
// Use the input file name so that we get a unique and identifiable
|
|
|
|
// output file for each ThinLTO backend task.
|
[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 09:46:41 +08:00
|
|
|
Filename = F.name;
|
2016-03-05 01:06:02 +08:00
|
|
|
Filename += ".thinlto.o";
|
|
|
|
}
|
|
|
|
bool TempOutFile = Filename.empty();
|
|
|
|
|
|
|
|
SmallString<128> NewFilename;
|
|
|
|
int FD = openOutputFile(Filename, TempOutFile, NewFilename,
|
|
|
|
// Only append the TaskID if we will use the
|
|
|
|
// non-unique obj_path.
|
|
|
|
!options::obj_path.empty() ? TaskCount : -1);
|
|
|
|
TaskCount++;
|
|
|
|
std::unique_ptr<raw_fd_ostream> OS =
|
|
|
|
llvm::make_unique<raw_fd_ostream>(FD, true);
|
|
|
|
|
|
|
|
// Enqueue the task
|
[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 09:46:41 +08:00
|
|
|
ThinLTOThreadPool.async(thinLTOBackendTask, std::ref(F), View, F.name,
|
|
|
|
ApiFile, std::ref(CombinedIndex), OS.get(),
|
|
|
|
TaskCount, std::ref(ModuleMap));
|
2016-03-05 01:06:02 +08:00
|
|
|
|
|
|
|
// Record the information needed by the task or during its cleanup
|
|
|
|
// to a ThinLTOTaskInfo instance. For information needed by the task
|
|
|
|
// the unique_ptr ownership is transferred to the ThinLTOTaskInfo.
|
[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 09:46:41 +08:00
|
|
|
Tasks.emplace_back(std::move(OS), NewFilename.c_str(), TempOutFile);
|
2016-03-05 01:06:02 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (auto &Task : Tasks)
|
|
|
|
Task.cleanup();
|
|
|
|
}
|
|
|
|
|
2016-05-17 22:45:30 +08:00
|
|
|
/// 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;
|
2016-05-18 02:43:22 +08:00
|
|
|
assert(PrefixReplace.empty() || PrefixReplace.find(";") != StringRef::npos);
|
|
|
|
std::pair<StringRef, StringRef> Split = PrefixReplace.split(";");
|
2016-05-17 22:45:30 +08:00
|
|
|
OldPrefix = Split.first.str();
|
|
|
|
NewPrefix = Split.second.str();
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Given the original \p Path to an output file, replace any path
|
|
|
|
/// prefix matching \p OldPrefix with \p NewPrefix. Also, create the
|
|
|
|
/// resulting directory if it does not yet exist.
|
|
|
|
static std::string getThinLTOOutputFile(const std::string &Path,
|
|
|
|
const std::string &OldPrefix,
|
|
|
|
const std::string &NewPrefix) {
|
|
|
|
if (OldPrefix.empty() && NewPrefix.empty())
|
|
|
|
return Path;
|
|
|
|
SmallString<128> NewPath(Path);
|
|
|
|
llvm::sys::path::replace_path_prefix(NewPath, OldPrefix, NewPrefix);
|
|
|
|
StringRef ParentPath = llvm::sys::path::parent_path(NewPath.str());
|
|
|
|
if (!ParentPath.empty()) {
|
|
|
|
// Make sure the new directory exists, creating it if necessary.
|
|
|
|
if (std::error_code EC = llvm::sys::fs::create_directories(ParentPath))
|
|
|
|
llvm::errs() << "warning: could not create directory '" << ParentPath
|
|
|
|
<< "': " << EC.message() << '\n';
|
|
|
|
}
|
|
|
|
return NewPath.str();
|
|
|
|
}
|
|
|
|
|
2016-05-10 21:48:23 +08:00
|
|
|
/// Perform ThinLTO link, which creates the combined index file.
|
|
|
|
/// Also, either launch backend threads or (under thinlto-index-only)
|
|
|
|
/// emit individual index files for distributed backends and exit.
|
|
|
|
static ld_plugin_status thinLTOLink(raw_fd_ostream *ApiFile) {
|
[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 09:46:41 +08:00
|
|
|
// Map from a module name to the corresponding buffer holding a view of the
|
|
|
|
// bitcode provided via the get_view gold callback.
|
|
|
|
StringMap<MemoryBufferRef> ModuleMap;
|
|
|
|
// Map to own RAII objects that manage the file opening and releasing
|
|
|
|
// interfaces with gold.
|
|
|
|
DenseMap<void *, std::unique_ptr<PluginInputFile>> HandleToInputFile;
|
|
|
|
|
2016-05-10 21:48:23 +08:00
|
|
|
ModuleSummaryIndex CombinedIndex;
|
|
|
|
uint64_t NextModuleId = 0;
|
|
|
|
for (claimed_file &F : 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 09:46:41 +08:00
|
|
|
if (!HandleToInputFile.count(F.leader_handle))
|
|
|
|
HandleToInputFile.insert(std::make_pair(
|
|
|
|
F.leader_handle, llvm::make_unique<PluginInputFile>(F.handle)));
|
|
|
|
// Pass this into getModuleSummaryIndexForFile
|
|
|
|
const void *View = getSymbolsAndView(F);
|
|
|
|
if (!View)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
MemoryBufferRef ModuleBuffer(StringRef((const char *)View, F.filesize),
|
|
|
|
F.name);
|
|
|
|
assert(ModuleMap.find(ModuleBuffer.getBufferIdentifier()) ==
|
|
|
|
ModuleMap.end() &&
|
|
|
|
"Expect unique Buffer Identifier");
|
|
|
|
ModuleMap[ModuleBuffer.getBufferIdentifier()] = ModuleBuffer;
|
2016-05-05 21:44:56 +08:00
|
|
|
|
[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 09:46:41 +08:00
|
|
|
std::unique_ptr<ModuleSummaryIndex> Index = getModuleSummaryIndexForFile(F);
|
2016-05-10 21:48:23 +08:00
|
|
|
|
|
|
|
// Skip files without a module summary.
|
|
|
|
if (Index)
|
|
|
|
CombinedIndex.mergeFrom(std::move(Index), ++NextModuleId);
|
|
|
|
}
|
2016-03-05 00:36:06 +08:00
|
|
|
|
2016-05-10 23:54:09 +08:00
|
|
|
if (options::thinlto_emit_imports_files && !options::thinlto_index_only)
|
|
|
|
message(LDPL_WARNING,
|
|
|
|
"thinlto-emit-imports-files ignored unless thinlto-index-only");
|
|
|
|
|
2016-05-10 21:48:23 +08:00
|
|
|
if (options::thinlto_index_only) {
|
|
|
|
// Collect for each module the list of function it defines (GUID ->
|
|
|
|
// Summary).
|
|
|
|
StringMap<std::map<GlobalValue::GUID, GlobalValueSummary *>>
|
|
|
|
ModuleToDefinedGVSummaries(NextModuleId);
|
|
|
|
CombinedIndex.collectDefinedGVSummariesPerModule(
|
|
|
|
ModuleToDefinedGVSummaries);
|
|
|
|
|
|
|
|
// FIXME: We want to do this for the case where the threads are launched
|
|
|
|
// from gold as well, in which case this will be moved out of the
|
|
|
|
// thinlto_index_only handling, and the function importer will be invoked
|
|
|
|
// directly using the Lists.
|
|
|
|
StringMap<FunctionImporter::ImportMapTy> ImportLists(NextModuleId);
|
|
|
|
StringMap<FunctionImporter::ExportSetTy> ExportLists(NextModuleId);
|
|
|
|
ComputeCrossModuleImport(CombinedIndex, ModuleToDefinedGVSummaries,
|
|
|
|
ImportLists, ExportLists);
|
|
|
|
|
2016-05-17 22:45:30 +08:00
|
|
|
// If the thinlto-prefix-replace option was specified, parse it and
|
|
|
|
// extract the old and new prefixes.
|
|
|
|
std::string OldPrefix, NewPrefix;
|
|
|
|
getThinLTOOldAndNewPrefix(OldPrefix, NewPrefix);
|
|
|
|
|
2016-05-10 21:48:23 +08:00
|
|
|
// For each input bitcode file, generate an individual index that
|
|
|
|
// contains summaries only for its own global values, and for any that
|
|
|
|
// should be imported.
|
2015-10-04 22:33:43 +08:00
|
|
|
for (claimed_file &F : Modules) {
|
2016-05-10 21:48:23 +08:00
|
|
|
std::error_code EC;
|
2016-05-17 22:45:30 +08:00
|
|
|
|
|
|
|
std::string NewModulePath =
|
[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 09:46:41 +08:00
|
|
|
getThinLTOOutputFile(F.name, OldPrefix, NewPrefix);
|
2016-05-17 22:45:30 +08:00
|
|
|
raw_fd_ostream OS((Twine(NewModulePath) + ".thinlto.bc").str(), EC,
|
|
|
|
sys::fs::OpenFlags::F_None);
|
2016-05-10 21:48:23 +08:00
|
|
|
if (EC)
|
|
|
|
message(LDPL_FATAL, "Unable to open %s.thinlto.bc for writing: %s",
|
2016-05-17 22:45:30 +08:00
|
|
|
NewModulePath.c_str(), EC.message().c_str());
|
2016-05-10 21:48:23 +08:00
|
|
|
// Build a map of module to the GUIDs and summary objects that should
|
|
|
|
// be written to its index.
|
|
|
|
std::map<std::string, GVSummaryMapTy> ModuleToSummariesForIndex;
|
[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 09:46:41 +08:00
|
|
|
gatherImportedSummariesForModule(F.name, ModuleToDefinedGVSummaries,
|
|
|
|
ImportLists, ModuleToSummariesForIndex);
|
2016-05-10 21:48:23 +08:00
|
|
|
WriteIndexToFile(CombinedIndex, OS, &ModuleToSummariesForIndex);
|
2016-05-10 23:54:09 +08:00
|
|
|
|
|
|
|
if (options::thinlto_emit_imports_files) {
|
[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 09:46:41 +08:00
|
|
|
if ((EC = EmitImportsFiles(F.name,
|
|
|
|
(Twine(NewModulePath) + ".imports").str(),
|
|
|
|
ImportLists)))
|
2016-05-10 23:54:09 +08:00
|
|
|
message(LDPL_FATAL, "Unable to open %s.imports",
|
2016-05-17 22:45:30 +08:00
|
|
|
NewModulePath.c_str(), EC.message().c_str());
|
2016-05-10 23:54:09 +08:00
|
|
|
}
|
2016-05-06 02:31:00 +08:00
|
|
|
}
|
2016-05-05 21:44:56 +08:00
|
|
|
|
2016-05-10 21:48:23 +08:00
|
|
|
cleanup_hook();
|
|
|
|
exit(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Create OS in nested scope so that it will be closed on destruction.
|
|
|
|
{
|
2015-10-04 22:33:43 +08:00
|
|
|
std::error_code EC;
|
|
|
|
raw_fd_ostream OS(output_name + ".thinlto.bc", EC,
|
|
|
|
sys::fs::OpenFlags::F_None);
|
|
|
|
if (EC)
|
|
|
|
message(LDPL_FATAL, "Unable to open %s.thinlto.bc for writing: %s",
|
|
|
|
output_name.data(), EC.message().c_str());
|
[ThinLTO] Support for reference graph in per-module and combined summary.
Summary:
This patch adds support for including a full reference graph including
call graph edges and other GV references in the summary.
The reference graph edges can be used to make importing decisions
without materializing any source modules, can be used in the plugin
to make file staging decisions for distributed build systems, and is
expected to have other uses.
The call graph edges are recorded in each function summary in the
bitcode via a list of <CalleeValueIds, StaticCount> tuples when no PGO
data exists, or <CalleeValueId, StaticCount, ProfileCount> pairs when
there is PGO, where the ValueId can be mapped to the function GUID via
the ValueSymbolTable. In the function index in memory, the call graph
edges reference the target via the CalleeGUID instead of the
CalleeValueId.
The reference graph edges are recorded in each summary record with a
list of referenced value IDs, which can be mapped to value GUID via the
ValueSymbolTable.
Addtionally, a new summary record type is added to record references
from global variable initializers. A number of bitcode records and data
structures have been renamed to reflect the newly expanded scope of the
summary beyond functions. More cleanup will follow.
Reviewers: joker.eph, davidxl
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D17212
llvm-svn: 263275
2016-03-12 02:52:24 +08:00
|
|
|
WriteIndexToFile(CombinedIndex, OS);
|
2016-05-10 21:48:23 +08:00
|
|
|
}
|
2015-10-04 22:33:43 +08:00
|
|
|
|
[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 09:46:41 +08:00
|
|
|
thinLTOBackends(ApiFile, CombinedIndex, ModuleMap);
|
2016-05-10 21:48:23 +08:00
|
|
|
return LDPS_OK;
|
|
|
|
}
|
2016-03-05 01:06:02 +08:00
|
|
|
|
2016-05-10 21:48:23 +08:00
|
|
|
/// 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(raw_fd_ostream *ApiFile) {
|
|
|
|
if (Modules.empty())
|
2016-03-05 01:06:02 +08:00
|
|
|
return LDPS_OK;
|
2016-05-10 21:48:23 +08:00
|
|
|
|
|
|
|
if (unsigned NumOpts = options::extra.size())
|
|
|
|
cl::ParseCommandLineOptions(NumOpts, &options::extra[0]);
|
|
|
|
|
|
|
|
if (options::thinlto)
|
|
|
|
return thinLTOLink(ApiFile);
|
2015-10-04 22:33:43 +08:00
|
|
|
|
2015-12-10 03:49:40 +08:00
|
|
|
LLVMContext Context;
|
2016-04-23 13:15:59 +08:00
|
|
|
Context.setDiscardValueNames(options::TheOutputType !=
|
|
|
|
options::OT_SAVE_TEMPS);
|
2016-04-19 12:55:25 +08:00
|
|
|
Context.enableDebugTypeODRUniquing(); // Merge debug info types.
|
2015-12-10 03:49:40 +08:00
|
|
|
Context.setDiagnosticHandler(diagnosticHandlerForContext, nullptr, true);
|
|
|
|
|
2014-08-22 04:28:55 +08:00
|
|
|
std::unique_ptr<Module> Combined(new Module("ld-temp.o", Context));
|
2015-12-15 07:17:03 +08:00
|
|
|
IRMover L(*Combined);
|
2010-06-03 22:45:44 +08:00
|
|
|
|
2014-08-22 04:28:55 +08:00
|
|
|
StringSet<> Internalize;
|
|
|
|
StringSet<> Maybe;
|
|
|
|
for (claimed_file &F : 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 09:46:41 +08:00
|
|
|
// RAII object to manage the file opening and releasing interfaces with
|
|
|
|
// gold.
|
2015-12-17 00:34:06 +08:00
|
|
|
PluginInputFile InputFile(F.handle);
|
2016-03-05 00:36:06 +08:00
|
|
|
const void *View = getSymbolsAndView(F);
|
2016-03-11 08:51:57 +08:00
|
|
|
if (!View)
|
|
|
|
continue;
|
2016-05-27 13:21:35 +08:00
|
|
|
linkInModule(Context, L, F, View, F.name, ApiFile, Internalize, Maybe);
|
2014-08-22 04:28:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
for (const auto &Name : Internalize) {
|
|
|
|
GlobalValue *GV = Combined->getNamedValue(Name.first());
|
|
|
|
if (GV)
|
|
|
|
internalize(*GV);
|
2010-06-15 05:20:52 +08:00
|
|
|
}
|
2009-02-03 15:13:24 +08:00
|
|
|
|
2014-08-22 04:28:55 +08:00
|
|
|
for (const auto &Name : Maybe) {
|
|
|
|
GlobalValue *GV = Combined->getNamedValue(Name.first());
|
|
|
|
if (!GV)
|
|
|
|
continue;
|
|
|
|
GV->setLinkage(GlobalValue::LinkOnceODRLinkage);
|
|
|
|
if (canBeOmittedFromSymbolTable(GV))
|
|
|
|
internalize(*GV);
|
|
|
|
}
|
2010-08-11 08:15:13 +08:00
|
|
|
|
2014-11-25 05:18:14 +08:00
|
|
|
if (options::TheOutputType == options::OT_DISABLE)
|
|
|
|
return LDPS_OK;
|
|
|
|
|
|
|
|
if (options::TheOutputType != options::OT_NORMAL) {
|
2010-06-04 05:11:20 +08:00
|
|
|
std::string path;
|
2014-11-25 05:18:14 +08:00
|
|
|
if (options::TheOutputType == options::OT_BC_ONLY)
|
2010-06-04 05:11:20 +08:00
|
|
|
path = output_name;
|
|
|
|
else
|
|
|
|
path = output_name + ".bc";
|
2015-12-02 03:50:54 +08:00
|
|
|
saveBCFile(path, *Combined);
|
2014-11-25 05:18:14 +08:00
|
|
|
if (options::TheOutputType == options::OT_BC_ONLY)
|
2014-08-12 03:06:54 +08:00
|
|
|
return LDPS_OK;
|
2010-05-13 21:39:31 +08:00
|
|
|
}
|
2013-10-16 20:47:04 +08:00
|
|
|
|
2016-03-05 00:36:06 +08:00
|
|
|
CodeGen codeGen(std::move(Combined));
|
|
|
|
codeGen.runAll();
|
2009-02-03 15:13:24 +08:00
|
|
|
|
2010-06-24 04:20:59 +08:00
|
|
|
if (!options::extra_library_path.empty() &&
|
2014-08-22 04:28:55 +08:00
|
|
|
set_extra_library_path(options::extra_library_path.c_str()) != LDPS_OK)
|
|
|
|
message(LDPL_FATAL, "Unable to set the extra library path.");
|
2013-08-13 05:07:31 +08:00
|
|
|
|
2009-02-03 15:13:24 +08:00
|
|
|
return LDPS_OK;
|
|
|
|
}
|
|
|
|
|
2014-08-12 03:06:54 +08:00
|
|
|
static ld_plugin_status all_symbols_read_hook(void) {
|
|
|
|
ld_plugin_status Ret;
|
|
|
|
if (!options::generate_api_file) {
|
|
|
|
Ret = allSymbolsReadHook(nullptr);
|
|
|
|
} else {
|
2014-08-26 02:16:47 +08:00
|
|
|
std::error_code EC;
|
|
|
|
raw_fd_ostream ApiFile("apifile.txt", EC, sys::fs::F_None);
|
|
|
|
if (EC)
|
2014-08-12 03:06:54 +08:00
|
|
|
message(LDPL_FATAL, "Unable to open apifile.txt for writing: %s",
|
2014-08-26 02:16:47 +08:00
|
|
|
EC.message().c_str());
|
2014-08-22 04:28:55 +08:00
|
|
|
Ret = allSymbolsReadHook(&ApiFile);
|
2014-08-12 03:06:54 +08:00
|
|
|
}
|
|
|
|
|
2014-11-26 04:52:49 +08:00
|
|
|
llvm_shutdown();
|
|
|
|
|
2014-11-25 05:18:14 +08:00
|
|
|
if (options::TheOutputType == options::OT_BC_ONLY ||
|
2015-02-13 02:21:50 +08:00
|
|
|
options::TheOutputType == options::OT_DISABLE) {
|
2016-03-21 04:12:33 +08:00
|
|
|
if (options::TheOutputType == options::OT_DISABLE) {
|
2015-02-13 02:21:50 +08:00
|
|
|
// Remove the output file here since ld.bfd creates the output file
|
|
|
|
// early.
|
2016-03-21 04:12:33 +08:00
|
|
|
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());
|
|
|
|
}
|
2014-08-12 03:06:54 +08:00
|
|
|
exit(0);
|
2015-02-13 02:21:50 +08:00
|
|
|
}
|
2014-08-12 03:06:54 +08:00
|
|
|
|
|
|
|
return Ret;
|
|
|
|
}
|
|
|
|
|
2010-04-16 08:42:57 +08:00
|
|
|
static ld_plugin_status cleanup_hook(void) {
|
2014-07-30 09:52:40 +08:00
|
|
|
for (std::string &Name : Cleanup) {
|
|
|
|
std::error_code EC = sys::fs::remove(Name);
|
2013-06-18 02:38:18 +08:00
|
|
|
if (EC)
|
2014-07-30 09:52:40 +08:00
|
|
|
message(LDPL_ERROR, "Failed to delete '%s': %s", Name.c_str(),
|
2014-07-30 08:38:58 +08:00
|
|
|
EC.message().c_str());
|
2013-06-18 02:38:18 +08:00
|
|
|
}
|
2009-02-03 15:13:24 +08:00
|
|
|
|
|
|
|
return LDPS_OK;
|
|
|
|
}
|