2013-05-27 18:15:31 -05:00
|
|
|
// Copyright 2013 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2013-08-22 22:58:42 -05:00
|
|
|
#include <stdio.h>
|
|
|
|
|
2017-06-29 09:52:43 -05:00
|
|
|
#include <vector>
|
2017-11-29 14:00:10 -06:00
|
|
|
#include <set>
|
2017-06-29 09:52:43 -05:00
|
|
|
|
2013-05-27 18:15:31 -05:00
|
|
|
#include "rustllvm.h"
|
|
|
|
|
rustc: Update LLVM
This commit updates the LLVM submodule in use to the current HEAD of the LLVM
repository. This is primarily being done to start picking up unwinding support
for MSVC, which is currently unimplemented in the revision of LLVM we are using.
Along the way a few changes had to be made:
* As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some
significant changes to our RustWrapper.cpp
* As usual, some pass management changed in LLVM, so clang was re-scrutinized to
ensure that we're doing the same thing as clang.
* Some optimization options are now passed directly into the
`PassManagerBuilder` instead of through CLI switches to LLVM.
* The `NoFramePointerElim` option was removed from LLVM, favoring instead the
`no-frame-pointer-elim` function attribute instead.
Additionally, LLVM has picked up some new optimizations which required fixing an
existing soundness hole in the IR we generate. It appears that the current LLVM
we use does not expose this hole. When an enum is moved, the previous slot in
memory is overwritten with a bit pattern corresponding to "dropped". When the
drop glue for this slot is run, however, the switch on the discriminant can
often start executing the `unreachable` block of the switch due to the
discriminant now being outside the normal range. This was patched over locally
for now by having the `unreachable` block just change to a `ret void`.
2015-05-14 14:10:43 -05:00
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
|
|
|
#include "llvm/Analysis/TargetTransformInfo.h"
|
2016-08-03 14:37:57 -05:00
|
|
|
#include "llvm/IR/AutoUpgrade.h"
|
2017-06-29 09:52:43 -05:00
|
|
|
#include "llvm/IR/AssemblyAnnotationWriter.h"
|
2016-12-30 05:22:11 -06:00
|
|
|
#include "llvm/Support/CBindingWrapping.h"
|
|
|
|
#include "llvm/Support/FileSystem.h"
|
|
|
|
#include "llvm/Support/Host.h"
|
2015-07-16 17:48:16 -05:00
|
|
|
#include "llvm/Target/TargetMachine.h"
|
2013-08-22 22:58:42 -05:00
|
|
|
#include "llvm/Transforms/IPO/PassManagerBuilder.h"
|
2013-05-27 18:15:31 -05:00
|
|
|
|
2018-01-22 19:01:36 -06:00
|
|
|
#if LLVM_VERSION_GE(6, 0)
|
|
|
|
#include "llvm/CodeGen/TargetSubtargetInfo.h"
|
2018-01-22 19:28:09 -06:00
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
2018-01-22 19:01:36 -06:00
|
|
|
#else
|
|
|
|
#include "llvm/Target/TargetSubtargetInfo.h"
|
|
|
|
#endif
|
|
|
|
|
2016-09-24 11:37:04 -05:00
|
|
|
#if LLVM_VERSION_GE(4, 0)
|
|
|
|
#include "llvm/Transforms/IPO/AlwaysInliner.h"
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
#include "llvm/Transforms/IPO/FunctionImport.h"
|
|
|
|
#include "llvm/Transforms/Utils/FunctionImportUtils.h"
|
|
|
|
#include "llvm/LTO/LTO.h"
|
2017-10-10 14:29:14 -05:00
|
|
|
#if LLVM_VERSION_LE(4, 0)
|
|
|
|
#include "llvm/Object/ModuleSummaryIndexObjectFile.h"
|
|
|
|
#endif
|
2016-09-24 11:37:04 -05:00
|
|
|
#endif
|
rustc: Update LLVM
This commit updates the LLVM submodule in use to the current HEAD of the LLVM
repository. This is primarily being done to start picking up unwinding support
for MSVC, which is currently unimplemented in the revision of LLVM we are using.
Along the way a few changes had to be made:
* As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some
significant changes to our RustWrapper.cpp
* As usual, some pass management changed in LLVM, so clang was re-scrutinized to
ensure that we're doing the same thing as clang.
* Some optimization options are now passed directly into the
`PassManagerBuilder` instead of through CLI switches to LLVM.
* The `NoFramePointerElim` option was removed from LLVM, favoring instead the
`no-frame-pointer-elim` function attribute instead.
Additionally, LLVM has picked up some new optimizations which required fixing an
existing soundness hole in the IR we generate. It appears that the current LLVM
we use does not expose this hole. When an enum is moved, the previous slot in
memory is overwritten with a bit pattern corresponding to "dropped". When the
drop glue for this slot is run, however, the switch on the discriminant can
often start executing the `unreachable` block of the switch due to the
discriminant now being outside the normal range. This was patched over locally
for now by having the `unreachable` block just change to a `ret void`.
2015-05-14 14:10:43 -05:00
|
|
|
|
2013-08-22 22:58:42 -05:00
|
|
|
#include "llvm-c/Transforms/PassManagerBuilder.h"
|
2013-05-27 18:15:31 -05:00
|
|
|
|
2018-03-15 10:56:45 -05:00
|
|
|
#if LLVM_VERSION_GE(4, 0)
|
|
|
|
#define PGO_AVAILABLE
|
|
|
|
#endif
|
|
|
|
|
2013-08-22 22:58:42 -05:00
|
|
|
using namespace llvm;
|
rustc: Update LLVM
This commit updates the LLVM submodule in use to the current HEAD of the LLVM
repository. This is primarily being done to start picking up unwinding support
for MSVC, which is currently unimplemented in the revision of LLVM we are using.
Along the way a few changes had to be made:
* As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some
significant changes to our RustWrapper.cpp
* As usual, some pass management changed in LLVM, so clang was re-scrutinized to
ensure that we're doing the same thing as clang.
* Some optimization options are now passed directly into the
`PassManagerBuilder` instead of through CLI switches to LLVM.
* The `NoFramePointerElim` option was removed from LLVM, favoring instead the
`no-frame-pointer-elim` function attribute instead.
Additionally, LLVM has picked up some new optimizations which required fixing an
existing soundness hole in the IR we generate. It appears that the current LLVM
we use does not expose this hole. When an enum is moved, the previous slot in
memory is overwritten with a bit pattern corresponding to "dropped". When the
drop glue for this slot is run, however, the switch on the discriminant can
often start executing the `unreachable` block of the switch due to the
discriminant now being outside the normal range. This was patched over locally
for now by having the `unreachable` block just change to a `ret void`.
2015-05-14 14:10:43 -05:00
|
|
|
using namespace llvm::legacy;
|
2013-05-27 18:15:31 -05:00
|
|
|
|
2013-08-22 22:58:42 -05:00
|
|
|
extern cl::opt<bool> EnableARMEHABI;
|
2013-05-27 18:15:31 -05:00
|
|
|
|
2013-08-22 22:58:42 -05:00
|
|
|
typedef struct LLVMOpaquePass *LLVMPassRef;
|
|
|
|
typedef struct LLVMOpaqueTargetMachine *LLVMTargetMachineRef;
|
|
|
|
|
|
|
|
DEFINE_STDCXX_CONVERSION_FUNCTIONS(Pass, LLVMPassRef)
|
|
|
|
DEFINE_STDCXX_CONVERSION_FUNCTIONS(TargetMachine, LLVMTargetMachineRef)
|
2016-12-30 05:22:11 -06:00
|
|
|
DEFINE_STDCXX_CONVERSION_FUNCTIONS(PassManagerBuilder,
|
|
|
|
LLVMPassManagerBuilderRef)
|
2013-05-27 18:15:31 -05:00
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" void LLVMInitializePasses() {
|
2013-05-29 03:08:20 -05:00
|
|
|
PassRegistry &Registry = *PassRegistry::getPassRegistry();
|
|
|
|
initializeCore(Registry);
|
|
|
|
initializeCodeGen(Registry);
|
|
|
|
initializeScalarOpts(Registry);
|
|
|
|
initializeVectorization(Registry);
|
|
|
|
initializeIPO(Registry);
|
|
|
|
initializeAnalysis(Registry);
|
|
|
|
initializeTransformUtils(Registry);
|
|
|
|
initializeInstCombine(Registry);
|
|
|
|
initializeInstrumentation(Registry);
|
|
|
|
initializeTarget(Registry);
|
|
|
|
}
|
2013-05-27 18:15:31 -05:00
|
|
|
|
2016-08-01 16:16:16 -05:00
|
|
|
enum class LLVMRustPassKind {
|
|
|
|
Other,
|
2016-01-24 19:22:24 -06:00
|
|
|
Function,
|
|
|
|
Module,
|
|
|
|
};
|
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
static LLVMRustPassKind toRust(PassKind Kind) {
|
|
|
|
switch (Kind) {
|
2016-08-01 16:16:16 -05:00
|
|
|
case PT_Function:
|
2016-12-30 05:22:11 -06:00
|
|
|
return LLVMRustPassKind::Function;
|
2016-08-01 16:16:16 -05:00
|
|
|
case PT_Module:
|
2016-12-30 05:22:11 -06:00
|
|
|
return LLVMRustPassKind::Module;
|
2016-08-01 16:16:16 -05:00
|
|
|
default:
|
2016-12-30 05:22:11 -06:00
|
|
|
return LLVMRustPassKind::Other;
|
2016-08-01 16:16:16 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" LLVMPassRef LLVMRustFindAndCreatePass(const char *PassName) {
|
|
|
|
StringRef SR(PassName);
|
|
|
|
PassRegistry *PR = PassRegistry::getPassRegistry();
|
2013-05-27 18:15:31 -05:00
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
const PassInfo *PI = PR->getPassInfo(SR);
|
|
|
|
if (PI) {
|
|
|
|
return wrap(PI->createPass());
|
|
|
|
}
|
2016-12-30 06:21:21 -06:00
|
|
|
return nullptr;
|
2016-01-24 19:22:24 -06:00
|
|
|
}
|
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
extern "C" LLVMRustPassKind LLVMRustPassKind(LLVMPassRef RustPass) {
|
|
|
|
assert(RustPass);
|
|
|
|
Pass *Pass = unwrap(RustPass);
|
|
|
|
return toRust(Pass->getPassKind());
|
2016-01-24 19:22:24 -06:00
|
|
|
}
|
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
extern "C" void LLVMRustAddPass(LLVMPassManagerRef PMR, LLVMPassRef RustPass) {
|
|
|
|
assert(RustPass);
|
|
|
|
Pass *Pass = unwrap(RustPass);
|
|
|
|
PassManagerBase *PMB = unwrap(PMR);
|
|
|
|
PMB->add(Pass);
|
2013-08-22 22:58:42 -05:00
|
|
|
}
|
|
|
|
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
extern "C"
|
|
|
|
bool LLVMRustPassManagerBuilderPopulateThinLTOPassManager(
|
|
|
|
LLVMPassManagerBuilderRef PMBR,
|
|
|
|
LLVMPassManagerRef PMR
|
|
|
|
) {
|
|
|
|
#if LLVM_VERSION_GE(4, 0)
|
|
|
|
unwrap(PMBR)->populateThinLTOPassManager(*unwrap(PMR));
|
|
|
|
return true;
|
|
|
|
#else
|
|
|
|
return false;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2016-02-16 10:07:30 -06:00
|
|
|
#ifdef LLVM_COMPONENT_X86
|
|
|
|
#define SUBTARGET_X86 SUBTARGET(X86)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_X86
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef LLVM_COMPONENT_ARM
|
|
|
|
#define SUBTARGET_ARM SUBTARGET(ARM)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_ARM
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef LLVM_COMPONENT_AARCH64
|
|
|
|
#define SUBTARGET_AARCH64 SUBTARGET(AArch64)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_AARCH64
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef LLVM_COMPONENT_MIPS
|
|
|
|
#define SUBTARGET_MIPS SUBTARGET(Mips)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_MIPS
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef LLVM_COMPONENT_POWERPC
|
|
|
|
#define SUBTARGET_PPC SUBTARGET(PPC)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_PPC
|
|
|
|
#endif
|
|
|
|
|
2016-08-28 13:18:28 -05:00
|
|
|
#ifdef LLVM_COMPONENT_SYSTEMZ
|
|
|
|
#define SUBTARGET_SYSTEMZ SUBTARGET(SystemZ)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_SYSTEMZ
|
|
|
|
#endif
|
|
|
|
|
2016-11-09 15:56:10 -06:00
|
|
|
#ifdef LLVM_COMPONENT_MSP430
|
|
|
|
#define SUBTARGET_MSP430 SUBTARGET(MSP430)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_MSP430
|
|
|
|
#endif
|
|
|
|
|
2016-12-03 10:53:31 -06:00
|
|
|
#ifdef LLVM_COMPONENT_SPARC
|
|
|
|
#define SUBTARGET_SPARC SUBTARGET(Sparc)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_SPARC
|
|
|
|
#endif
|
|
|
|
|
2017-04-09 01:03:31 -05:00
|
|
|
#ifdef LLVM_COMPONENT_HEXAGON
|
|
|
|
#define SUBTARGET_HEXAGON SUBTARGET(Hexagon)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_HEXAGON
|
|
|
|
#endif
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
#define GEN_SUBTARGETS \
|
|
|
|
SUBTARGET_X86 \
|
|
|
|
SUBTARGET_ARM \
|
|
|
|
SUBTARGET_AARCH64 \
|
|
|
|
SUBTARGET_MIPS \
|
|
|
|
SUBTARGET_PPC \
|
|
|
|
SUBTARGET_SYSTEMZ \
|
2016-12-31 21:40:10 -06:00
|
|
|
SUBTARGET_MSP430 \
|
2017-04-09 01:03:31 -05:00
|
|
|
SUBTARGET_SPARC \
|
|
|
|
SUBTARGET_HEXAGON
|
2016-12-30 05:22:11 -06:00
|
|
|
|
|
|
|
#define SUBTARGET(x) \
|
|
|
|
namespace llvm { \
|
|
|
|
extern const SubtargetFeatureKV x##FeatureKV[]; \
|
|
|
|
extern const SubtargetFeatureKV x##SubTypeKV[]; \
|
2016-02-16 10:07:30 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
GEN_SUBTARGETS
|
|
|
|
#undef SUBTARGET
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" bool LLVMRustHasFeature(LLVMTargetMachineRef TM,
|
2016-12-31 11:01:23 -06:00
|
|
|
const char *Feature) {
|
2018-03-27 14:27:45 -05:00
|
|
|
#if LLVM_VERSION_GE(6, 0)
|
2016-12-30 05:22:11 -06:00
|
|
|
TargetMachine *Target = unwrap(TM);
|
|
|
|
const MCSubtargetInfo *MCInfo = Target->getMCSubtargetInfo();
|
2018-03-27 14:27:45 -05:00
|
|
|
return MCInfo->checkFeatures(std::string("+") + Feature);
|
|
|
|
#else
|
2017-07-27 21:03:23 -05:00
|
|
|
return false;
|
2018-03-27 14:27:45 -05:00
|
|
|
#endif
|
2016-02-16 10:07:30 -06:00
|
|
|
}
|
|
|
|
|
2016-08-01 16:16:16 -05:00
|
|
|
enum class LLVMRustCodeModel {
|
2016-12-30 05:22:11 -06:00
|
|
|
Other,
|
|
|
|
Small,
|
|
|
|
Kernel,
|
|
|
|
Medium,
|
|
|
|
Large,
|
2018-01-22 19:01:36 -06:00
|
|
|
None,
|
2016-08-01 16:16:16 -05:00
|
|
|
};
|
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
static CodeModel::Model fromRust(LLVMRustCodeModel Model) {
|
|
|
|
switch (Model) {
|
2016-12-30 05:22:11 -06:00
|
|
|
case LLVMRustCodeModel::Small:
|
|
|
|
return CodeModel::Small;
|
|
|
|
case LLVMRustCodeModel::Kernel:
|
|
|
|
return CodeModel::Kernel;
|
|
|
|
case LLVMRustCodeModel::Medium:
|
|
|
|
return CodeModel::Medium;
|
|
|
|
case LLVMRustCodeModel::Large:
|
|
|
|
return CodeModel::Large;
|
|
|
|
default:
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("Bad CodeModel.");
|
2016-08-01 16:16:16 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
enum class LLVMRustCodeGenOptLevel {
|
2016-12-30 05:22:11 -06:00
|
|
|
Other,
|
|
|
|
None,
|
|
|
|
Less,
|
|
|
|
Default,
|
|
|
|
Aggressive,
|
2016-08-01 16:16:16 -05:00
|
|
|
};
|
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
static CodeGenOpt::Level fromRust(LLVMRustCodeGenOptLevel Level) {
|
|
|
|
switch (Level) {
|
2016-12-30 05:22:11 -06:00
|
|
|
case LLVMRustCodeGenOptLevel::None:
|
|
|
|
return CodeGenOpt::None;
|
|
|
|
case LLVMRustCodeGenOptLevel::Less:
|
|
|
|
return CodeGenOpt::Less;
|
|
|
|
case LLVMRustCodeGenOptLevel::Default:
|
|
|
|
return CodeGenOpt::Default;
|
|
|
|
case LLVMRustCodeGenOptLevel::Aggressive:
|
|
|
|
return CodeGenOpt::Aggressive;
|
|
|
|
default:
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("Bad CodeGenOptLevel.");
|
2016-08-01 16:16:16 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-28 17:21:59 -05:00
|
|
|
enum class LLVMRustRelocMode {
|
|
|
|
Default,
|
|
|
|
Static,
|
|
|
|
PIC,
|
|
|
|
DynamicNoPic,
|
|
|
|
ROPI,
|
|
|
|
RWPI,
|
|
|
|
ROPIRWPI,
|
|
|
|
};
|
|
|
|
|
|
|
|
static Optional<Reloc::Model> fromRust(LLVMRustRelocMode RustReloc) {
|
|
|
|
switch (RustReloc) {
|
|
|
|
case LLVMRustRelocMode::Default:
|
|
|
|
return None;
|
|
|
|
case LLVMRustRelocMode::Static:
|
|
|
|
return Reloc::Static;
|
|
|
|
case LLVMRustRelocMode::PIC:
|
|
|
|
return Reloc::PIC_;
|
|
|
|
case LLVMRustRelocMode::DynamicNoPic:
|
|
|
|
return Reloc::DynamicNoPIC;
|
|
|
|
#if LLVM_VERSION_GE(4, 0)
|
|
|
|
case LLVMRustRelocMode::ROPI:
|
|
|
|
return Reloc::ROPI;
|
|
|
|
case LLVMRustRelocMode::RWPI:
|
|
|
|
return Reloc::RWPI;
|
|
|
|
case LLVMRustRelocMode::ROPIRWPI:
|
|
|
|
return Reloc::ROPI_RWPI;
|
2017-08-08 03:17:33 -05:00
|
|
|
#else
|
2017-04-28 17:21:59 -05:00
|
|
|
default:
|
2017-08-08 03:17:33 -05:00
|
|
|
break;
|
|
|
|
#endif
|
2017-04-28 17:21:59 -05:00
|
|
|
}
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("Bad RelocModel.");
|
2017-04-28 17:21:59 -05:00
|
|
|
}
|
|
|
|
|
2016-07-24 04:49:10 -05:00
|
|
|
#if LLVM_RUSTLLVM
|
2016-07-10 09:22:13 -05:00
|
|
|
/// getLongestEntryLength - Return the length of the longest entry in the table.
|
|
|
|
///
|
|
|
|
static size_t getLongestEntryLength(ArrayRef<SubtargetFeatureKV> Table) {
|
|
|
|
size_t MaxLen = 0;
|
|
|
|
for (auto &I : Table)
|
|
|
|
MaxLen = std::max(MaxLen, std::strlen(I.Key));
|
|
|
|
return MaxLen;
|
|
|
|
}
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" void LLVMRustPrintTargetCPUs(LLVMTargetMachineRef TM) {
|
|
|
|
const TargetMachine *Target = unwrap(TM);
|
|
|
|
const MCSubtargetInfo *MCInfo = Target->getMCSubtargetInfo();
|
2017-09-07 20:07:16 -05:00
|
|
|
const Triple::ArchType HostArch = Triple(sys::getProcessTriple()).getArch();
|
|
|
|
const Triple::ArchType TargetArch = Target->getTargetTriple().getArch();
|
2016-12-30 05:22:11 -06:00
|
|
|
const ArrayRef<SubtargetFeatureKV> CPUTable = MCInfo->getCPUTable();
|
|
|
|
unsigned MaxCPULen = getLongestEntryLength(CPUTable);
|
|
|
|
|
|
|
|
printf("Available CPUs for this target:\n");
|
2017-09-07 20:07:16 -05:00
|
|
|
if (HostArch == TargetArch) {
|
|
|
|
const StringRef HostCPU = sys::getHostCPUName();
|
|
|
|
printf(" %-*s - Select the CPU of the current host (currently %.*s).\n",
|
|
|
|
MaxCPULen, "native", (int)HostCPU.size(), HostCPU.data());
|
|
|
|
}
|
2016-12-30 05:22:11 -06:00
|
|
|
for (auto &CPU : CPUTable)
|
|
|
|
printf(" %-*s - %s.\n", MaxCPULen, CPU.Key, CPU.Desc);
|
|
|
|
printf("\n");
|
2016-07-10 09:22:13 -05:00
|
|
|
}
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" void LLVMRustPrintTargetFeatures(LLVMTargetMachineRef TM) {
|
|
|
|
const TargetMachine *Target = unwrap(TM);
|
|
|
|
const MCSubtargetInfo *MCInfo = Target->getMCSubtargetInfo();
|
|
|
|
const ArrayRef<SubtargetFeatureKV> FeatTable = MCInfo->getFeatureTable();
|
|
|
|
unsigned MaxFeatLen = getLongestEntryLength(FeatTable);
|
|
|
|
|
|
|
|
printf("Available features for this target:\n");
|
|
|
|
for (auto &Feature : FeatTable)
|
|
|
|
printf(" %-*s - %s.\n", MaxFeatLen, Feature.Key, Feature.Desc);
|
|
|
|
printf("\n");
|
|
|
|
|
|
|
|
printf("Use +feature to enable a feature, or -feature to disable it.\n"
|
|
|
|
"For example, rustc -C -target-cpu=mycpu -C "
|
|
|
|
"target-feature=+feature1,-feature2\n\n");
|
2016-07-10 09:22:13 -05:00
|
|
|
}
|
|
|
|
|
2016-07-24 04:49:10 -05:00
|
|
|
#else
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" void LLVMRustPrintTargetCPUs(LLVMTargetMachineRef) {
|
|
|
|
printf("Target CPU help is not supported by this LLVM version.\n\n");
|
2016-07-24 04:49:10 -05:00
|
|
|
}
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" void LLVMRustPrintTargetFeatures(LLVMTargetMachineRef) {
|
|
|
|
printf("Target features help is not supported by this LLVM version.\n\n");
|
2016-07-24 04:49:10 -05:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" LLVMTargetMachineRef LLVMRustCreateTargetMachine(
|
2016-12-31 11:01:23 -06:00
|
|
|
const char *TripleStr, const char *CPU, const char *Feature,
|
2017-04-28 17:21:59 -05:00
|
|
|
LLVMRustCodeModel RustCM, LLVMRustRelocMode RustReloc,
|
2016-12-31 11:01:23 -06:00
|
|
|
LLVMRustCodeGenOptLevel RustOptLevel, bool UseSoftFloat,
|
2016-12-30 05:22:11 -06:00
|
|
|
bool PositionIndependentExecutable, bool FunctionSections,
|
2017-10-22 22:01:00 -05:00
|
|
|
bool DataSections,
|
|
|
|
bool TrapUnreachable,
|
|
|
|
bool Singlethread) {
|
2016-07-24 15:31:16 -05:00
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
auto OptLevel = fromRust(RustOptLevel);
|
2017-04-28 17:21:59 -05:00
|
|
|
auto RM = fromRust(RustReloc);
|
2016-07-24 15:31:16 -05:00
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
std::string Error;
|
2016-12-31 11:01:23 -06:00
|
|
|
Triple Trip(Triple::normalize(TripleStr));
|
2016-12-30 05:22:11 -06:00
|
|
|
const llvm::Target *TheTarget =
|
|
|
|
TargetRegistry::lookupTarget(Trip.getTriple(), Error);
|
2016-12-30 06:21:21 -06:00
|
|
|
if (TheTarget == nullptr) {
|
2016-12-30 05:22:11 -06:00
|
|
|
LLVMRustSetLastError(Error.c_str());
|
2016-12-30 06:21:21 -06:00
|
|
|
return nullptr;
|
2016-12-30 05:22:11 -06:00
|
|
|
}
|
2013-08-22 22:58:42 -05:00
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
StringRef RealCPU = CPU;
|
|
|
|
if (RealCPU == "native") {
|
|
|
|
RealCPU = sys::getHostCPUName();
|
2016-12-30 05:22:11 -06:00
|
|
|
}
|
2015-03-09 19:46:45 -05:00
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
TargetOptions Options;
|
2016-07-12 17:41:40 -05:00
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
Options.FloatABIType = FloatABI::Default;
|
|
|
|
if (UseSoftFloat) {
|
|
|
|
Options.FloatABIType = FloatABI::Soft;
|
|
|
|
}
|
|
|
|
Options.DataSections = DataSections;
|
|
|
|
Options.FunctionSections = FunctionSections;
|
|
|
|
|
2017-11-11 09:08:00 -06:00
|
|
|
if (TrapUnreachable) {
|
|
|
|
// Tell LLVM to translate `unreachable` into an explicit trap instruction.
|
|
|
|
// This limits the extent of possible undefined behavior in some cases, as
|
|
|
|
// it prevents control flow from "falling through" into whatever code
|
|
|
|
// happens to be laid out next in memory.
|
|
|
|
Options.TrapUnreachable = true;
|
|
|
|
}
|
2017-11-10 13:00:52 -06:00
|
|
|
|
2017-10-22 22:01:00 -05:00
|
|
|
if (Singlethread) {
|
|
|
|
Options.ThreadModel = ThreadModel::Single;
|
|
|
|
}
|
|
|
|
|
2018-01-22 19:01:36 -06:00
|
|
|
#if LLVM_VERSION_GE(6, 0)
|
|
|
|
Optional<CodeModel::Model> CM;
|
|
|
|
#else
|
|
|
|
CodeModel::Model CM = CodeModel::Model::Default;
|
|
|
|
#endif
|
|
|
|
if (RustCM != LLVMRustCodeModel::None)
|
|
|
|
CM = fromRust(RustCM);
|
2016-12-30 05:22:11 -06:00
|
|
|
TargetMachine *TM = TheTarget->createTargetMachine(
|
2016-12-31 11:01:23 -06:00
|
|
|
Trip.getTriple(), RealCPU, Feature, Options, RM, CM, OptLevel);
|
2016-12-30 05:22:11 -06:00
|
|
|
return wrap(TM);
|
2013-08-22 22:58:42 -05:00
|
|
|
}
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" void LLVMRustDisposeTargetMachine(LLVMTargetMachineRef TM) {
|
|
|
|
delete unwrap(TM);
|
2013-08-22 22:58:42 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// Unfortunately, LLVM doesn't expose a C API to add the corresponding analysis
|
|
|
|
// passes for a target to a pass manager. We export that functionality through
|
|
|
|
// this function.
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" void LLVMRustAddAnalysisPasses(LLVMTargetMachineRef TM,
|
|
|
|
LLVMPassManagerRef PMR,
|
|
|
|
LLVMModuleRef M) {
|
|
|
|
PassManagerBase *PM = unwrap(PMR);
|
|
|
|
PM->add(
|
|
|
|
createTargetTransformInfoWrapperPass(unwrap(TM)->getTargetIRAnalysis()));
|
rustc: Update LLVM
This commit updates the LLVM submodule in use to the current HEAD of the LLVM
repository. This is primarily being done to start picking up unwinding support
for MSVC, which is currently unimplemented in the revision of LLVM we are using.
Along the way a few changes had to be made:
* As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some
significant changes to our RustWrapper.cpp
* As usual, some pass management changed in LLVM, so clang was re-scrutinized to
ensure that we're doing the same thing as clang.
* Some optimization options are now passed directly into the
`PassManagerBuilder` instead of through CLI switches to LLVM.
* The `NoFramePointerElim` option was removed from LLVM, favoring instead the
`no-frame-pointer-elim` function attribute instead.
Additionally, LLVM has picked up some new optimizations which required fixing an
existing soundness hole in the IR we generate. It appears that the current LLVM
we use does not expose this hole. When an enum is moved, the previous slot in
memory is overwritten with a bit pattern corresponding to "dropped". When the
drop glue for this slot is run, however, the switch on the discriminant can
often start executing the `unreachable` block of the switch due to the
discriminant now being outside the normal range. This was patched over locally
for now by having the `unreachable` block just change to a `ret void`.
2015-05-14 14:10:43 -05:00
|
|
|
}
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" void LLVMRustConfigurePassManagerBuilder(
|
2016-12-31 11:01:23 -06:00
|
|
|
LLVMPassManagerBuilderRef PMBR, LLVMRustCodeGenOptLevel OptLevel,
|
2018-05-12 07:07:20 -05:00
|
|
|
bool MergeFunctions, bool SLPVectorize, bool LoopVectorize, bool PrepareForThinLTO,
|
2018-02-18 18:57:12 -06:00
|
|
|
const char* PGOGenPath, const char* PGOUsePath) {
|
2018-03-29 02:41:41 -05:00
|
|
|
#if LLVM_RUSTLLVM
|
|
|
|
unwrap(PMBR)->MergeFunctions = MergeFunctions;
|
|
|
|
#endif
|
2016-12-31 11:01:23 -06:00
|
|
|
unwrap(PMBR)->SLPVectorize = SLPVectorize;
|
|
|
|
unwrap(PMBR)->OptLevel = fromRust(OptLevel);
|
|
|
|
unwrap(PMBR)->LoopVectorize = LoopVectorize;
|
2018-05-12 07:07:20 -05:00
|
|
|
#if LLVM_VERSION_GE(4, 0)
|
|
|
|
unwrap(PMBR)->PrepareForThinLTO = PrepareForThinLTO;
|
|
|
|
#endif
|
2018-03-15 10:56:45 -05:00
|
|
|
|
|
|
|
#ifdef PGO_AVAILABLE
|
2018-02-18 18:57:12 -06:00
|
|
|
if (PGOGenPath) {
|
|
|
|
assert(!PGOUsePath);
|
|
|
|
unwrap(PMBR)->EnablePGOInstrGen = true;
|
|
|
|
unwrap(PMBR)->PGOInstrGen = PGOGenPath;
|
|
|
|
}
|
|
|
|
if (PGOUsePath) {
|
|
|
|
assert(!PGOGenPath);
|
|
|
|
unwrap(PMBR)->PGOInstrUse = PGOUsePath;
|
|
|
|
}
|
2018-03-15 10:56:45 -05:00
|
|
|
#else
|
|
|
|
assert(!PGOGenPath && !PGOUsePath && "Should've caught earlier");
|
|
|
|
#endif
|
2013-08-22 22:58:42 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// Unfortunately, the LLVM C API doesn't provide a way to set the `LibraryInfo`
|
|
|
|
// field of a PassManagerBuilder, we expose our own method of doing so.
|
2016-12-31 11:01:23 -06:00
|
|
|
extern "C" void LLVMRustAddBuilderLibraryInfo(LLVMPassManagerBuilderRef PMBR,
|
2016-12-30 05:22:11 -06:00
|
|
|
LLVMModuleRef M,
|
|
|
|
bool DisableSimplifyLibCalls) {
|
|
|
|
Triple TargetTriple(unwrap(M)->getTargetTriple());
|
|
|
|
TargetLibraryInfoImpl *TLI = new TargetLibraryInfoImpl(TargetTriple);
|
|
|
|
if (DisableSimplifyLibCalls)
|
|
|
|
TLI->disableAllFunctions();
|
2016-12-31 11:01:23 -06:00
|
|
|
unwrap(PMBR)->LibraryInfo = TLI;
|
2013-08-22 22:58:42 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// Unfortunately, the LLVM C API doesn't provide a way to create the
|
|
|
|
// TargetLibraryInfo pass, so we use this method to do so.
|
2016-12-31 11:01:23 -06:00
|
|
|
extern "C" void LLVMRustAddLibraryInfo(LLVMPassManagerRef PMR, LLVMModuleRef M,
|
2016-12-30 05:22:11 -06:00
|
|
|
bool DisableSimplifyLibCalls) {
|
|
|
|
Triple TargetTriple(unwrap(M)->getTargetTriple());
|
|
|
|
TargetLibraryInfoImpl TLII(TargetTriple);
|
|
|
|
if (DisableSimplifyLibCalls)
|
|
|
|
TLII.disableAllFunctions();
|
2016-12-31 11:01:23 -06:00
|
|
|
unwrap(PMR)->add(new TargetLibraryInfoWrapperPass(TLII));
|
2013-08-22 22:58:42 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// Unfortunately, the LLVM C API doesn't provide an easy way of iterating over
|
|
|
|
// all the functions in a module, so we do that manually here. You'll find
|
|
|
|
// similar code in clang's BackendUtil.cpp file.
|
2016-12-31 11:01:23 -06:00
|
|
|
extern "C" void LLVMRustRunFunctionPassManager(LLVMPassManagerRef PMR,
|
2016-12-30 05:22:11 -06:00
|
|
|
LLVMModuleRef M) {
|
|
|
|
llvm::legacy::FunctionPassManager *P =
|
2016-12-31 11:01:23 -06:00
|
|
|
unwrap<llvm::legacy::FunctionPassManager>(PMR);
|
2016-12-30 05:22:11 -06:00
|
|
|
P->doInitialization();
|
|
|
|
|
|
|
|
// Upgrade all calls to old intrinsics first.
|
|
|
|
for (Module::iterator I = unwrap(M)->begin(), E = unwrap(M)->end(); I != E;)
|
|
|
|
UpgradeCallsToIntrinsic(&*I++); // must be post-increment, as we remove
|
|
|
|
|
|
|
|
for (Module::iterator I = unwrap(M)->begin(), E = unwrap(M)->end(); I != E;
|
|
|
|
++I)
|
|
|
|
if (!I->isDeclaration())
|
|
|
|
P->run(*I);
|
|
|
|
|
|
|
|
P->doFinalization();
|
2013-08-22 22:58:42 -05:00
|
|
|
}
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" void LLVMRustSetLLVMOptions(int Argc, char **Argv) {
|
|
|
|
// Initializing the command-line options more than once is not allowed. So,
|
|
|
|
// check if they've already been initialized. (This could happen if we're
|
|
|
|
// being called from rustpkg, for example). If the arguments change, then
|
|
|
|
// that's just kinda unfortunate.
|
2016-12-31 11:01:23 -06:00
|
|
|
static bool Initialized = false;
|
|
|
|
if (Initialized)
|
2016-12-30 05:22:11 -06:00
|
|
|
return;
|
2016-12-31 11:01:23 -06:00
|
|
|
Initialized = true;
|
2016-12-30 05:22:11 -06:00
|
|
|
cl::ParseCommandLineOptions(Argc, Argv);
|
2013-08-22 22:58:42 -05:00
|
|
|
}
|
|
|
|
|
2016-08-01 16:16:16 -05:00
|
|
|
enum class LLVMRustFileType {
|
2016-12-30 05:22:11 -06:00
|
|
|
Other,
|
|
|
|
AssemblyFile,
|
|
|
|
ObjectFile,
|
2016-08-01 16:16:16 -05:00
|
|
|
};
|
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
static TargetMachine::CodeGenFileType fromRust(LLVMRustFileType Type) {
|
|
|
|
switch (Type) {
|
2016-12-30 05:22:11 -06:00
|
|
|
case LLVMRustFileType::AssemblyFile:
|
|
|
|
return TargetMachine::CGFT_AssemblyFile;
|
|
|
|
case LLVMRustFileType::ObjectFile:
|
|
|
|
return TargetMachine::CGFT_ObjectFile;
|
|
|
|
default:
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("Bad FileType.");
|
2016-08-01 16:16:16 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" LLVMRustResult
|
2016-12-30 05:22:11 -06:00
|
|
|
LLVMRustWriteOutputFile(LLVMTargetMachineRef Target, LLVMPassManagerRef PMR,
|
2016-12-31 11:01:23 -06:00
|
|
|
LLVMModuleRef M, const char *Path,
|
|
|
|
LLVMRustFileType RustFileType) {
|
2016-07-12 17:42:20 -05:00
|
|
|
llvm::legacy::PassManager *PM = unwrap<llvm::legacy::PassManager>(PMR);
|
2016-12-31 11:01:23 -06:00
|
|
|
auto FileType = fromRust(RustFileType);
|
2013-08-22 22:58:42 -05:00
|
|
|
|
|
|
|
std::string ErrorInfo;
|
2014-09-30 16:20:22 -05:00
|
|
|
std::error_code EC;
|
2016-12-31 11:01:23 -06:00
|
|
|
raw_fd_ostream OS(Path, EC, sys::fs::F_None);
|
2014-09-30 16:20:22 -05:00
|
|
|
if (EC)
|
|
|
|
ErrorInfo = EC.message();
|
2013-08-22 22:58:42 -05:00
|
|
|
if (ErrorInfo != "") {
|
2014-04-15 09:25:22 -05:00
|
|
|
LLVMRustSetLastError(ErrorInfo.c_str());
|
2016-08-01 16:16:16 -05:00
|
|
|
return LLVMRustResult::Failure;
|
2013-08-22 22:58:42 -05:00
|
|
|
}
|
|
|
|
|
rustc: Update LLVM
This commit updates the LLVM submodule in use to the current HEAD of the LLVM
repository. This is primarily being done to start picking up unwinding support
for MSVC, which is currently unimplemented in the revision of LLVM we are using.
Along the way a few changes had to be made:
* As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some
significant changes to our RustWrapper.cpp
* As usual, some pass management changed in LLVM, so clang was re-scrutinized to
ensure that we're doing the same thing as clang.
* Some optimization options are now passed directly into the
`PassManagerBuilder` instead of through CLI switches to LLVM.
* The `NoFramePointerElim` option was removed from LLVM, favoring instead the
`no-frame-pointer-elim` function attribute instead.
Additionally, LLVM has picked up some new optimizations which required fixing an
existing soundness hole in the IR we generate. It appears that the current LLVM
we use does not expose this hole. When an enum is moved, the previous slot in
memory is overwritten with a bit pattern corresponding to "dropped". When the
drop glue for this slot is run, however, the switch on the discriminant can
often start executing the `unreachable` block of the switch due to the
discriminant now being outside the normal range. This was patched over locally
for now by having the `unreachable` block just change to a `ret void`.
2015-05-14 14:10:43 -05:00
|
|
|
unwrap(Target)->addPassesToEmitFile(*PM, OS, FileType, false);
|
2013-08-22 22:58:42 -05:00
|
|
|
PM->run(*unwrap(M));
|
rustc: Update LLVM
This commit updates the LLVM submodule in use to the current HEAD of the LLVM
repository. This is primarily being done to start picking up unwinding support
for MSVC, which is currently unimplemented in the revision of LLVM we are using.
Along the way a few changes had to be made:
* As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some
significant changes to our RustWrapper.cpp
* As usual, some pass management changed in LLVM, so clang was re-scrutinized to
ensure that we're doing the same thing as clang.
* Some optimization options are now passed directly into the
`PassManagerBuilder` instead of through CLI switches to LLVM.
* The `NoFramePointerElim` option was removed from LLVM, favoring instead the
`no-frame-pointer-elim` function attribute instead.
Additionally, LLVM has picked up some new optimizations which required fixing an
existing soundness hole in the IR we generate. It appears that the current LLVM
we use does not expose this hole. When an enum is moved, the previous slot in
memory is overwritten with a bit pattern corresponding to "dropped". When the
drop glue for this slot is run, however, the switch on the discriminant can
often start executing the `unreachable` block of the switch due to the
discriminant now being outside the normal range. This was patched over locally
for now by having the `unreachable` block just change to a `ret void`.
2015-05-14 14:10:43 -05:00
|
|
|
|
2015-10-07 17:11:25 -05:00
|
|
|
// Apparently `addPassesToEmitFile` adds a pointer to our on-the-stack output
|
rustc: Update LLVM
This commit updates the LLVM submodule in use to the current HEAD of the LLVM
repository. This is primarily being done to start picking up unwinding support
for MSVC, which is currently unimplemented in the revision of LLVM we are using.
Along the way a few changes had to be made:
* As usual, lots of C++ debuginfo bindings in LLVM changed, so there were some
significant changes to our RustWrapper.cpp
* As usual, some pass management changed in LLVM, so clang was re-scrutinized to
ensure that we're doing the same thing as clang.
* Some optimization options are now passed directly into the
`PassManagerBuilder` instead of through CLI switches to LLVM.
* The `NoFramePointerElim` option was removed from LLVM, favoring instead the
`no-frame-pointer-elim` function attribute instead.
Additionally, LLVM has picked up some new optimizations which required fixing an
existing soundness hole in the IR we generate. It appears that the current LLVM
we use does not expose this hole. When an enum is moved, the previous slot in
memory is overwritten with a bit pattern corresponding to "dropped". When the
drop glue for this slot is run, however, the switch on the discriminant can
often start executing the `unreachable` block of the switch due to the
discriminant now being outside the normal range. This was patched over locally
for now by having the `unreachable` block just change to a `ret void`.
2015-05-14 14:10:43 -05:00
|
|
|
// stream (OS), so the only real safe place to delete this is here? Don't we
|
|
|
|
// wish this was written in Rust?
|
|
|
|
delete PM;
|
2016-08-01 16:16:16 -05:00
|
|
|
return LLVMRustResult::Success;
|
2013-08-22 22:58:42 -05:00
|
|
|
}
|
|
|
|
|
2017-06-29 09:52:43 -05:00
|
|
|
|
|
|
|
// Callback to demangle function name
|
|
|
|
// Parameters:
|
|
|
|
// * name to be demangled
|
|
|
|
// * name len
|
|
|
|
// * output buffer
|
|
|
|
// * output buffer len
|
|
|
|
// Returns len of demangled string, or 0 if demangle failed.
|
|
|
|
typedef size_t (*DemangleFn)(const char*, size_t, char*, size_t);
|
|
|
|
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
class RustAssemblyAnnotationWriter : public AssemblyAnnotationWriter {
|
|
|
|
DemangleFn Demangle;
|
|
|
|
std::vector<char> Buf;
|
|
|
|
|
|
|
|
public:
|
|
|
|
RustAssemblyAnnotationWriter(DemangleFn Demangle) : Demangle(Demangle) {}
|
|
|
|
|
|
|
|
// Return empty string if demangle failed
|
|
|
|
// or if name does not need to be demangled
|
|
|
|
StringRef CallDemangle(StringRef name) {
|
|
|
|
if (!Demangle) {
|
|
|
|
return StringRef();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Buf.size() < name.size() * 2) {
|
|
|
|
// Semangled name usually shorter than mangled,
|
|
|
|
// but allocate twice as much memory just in case
|
|
|
|
Buf.resize(name.size() * 2);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto R = Demangle(name.data(), name.size(), Buf.data(), Buf.size());
|
|
|
|
if (!R) {
|
|
|
|
// Demangle failed.
|
|
|
|
return StringRef();
|
|
|
|
}
|
|
|
|
|
|
|
|
auto Demangled = StringRef(Buf.data(), R);
|
|
|
|
if (Demangled == name) {
|
|
|
|
// Do not print anything if demangled name is equal to mangled.
|
|
|
|
return StringRef();
|
|
|
|
}
|
|
|
|
|
|
|
|
return Demangled;
|
|
|
|
}
|
|
|
|
|
|
|
|
void emitFunctionAnnot(const Function *F,
|
|
|
|
formatted_raw_ostream &OS) override {
|
|
|
|
StringRef Demangled = CallDemangle(F->getName());
|
|
|
|
if (Demangled.empty()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
OS << "; " << Demangled << "\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
void emitInstructionAnnot(const Instruction *I,
|
|
|
|
formatted_raw_ostream &OS) override {
|
|
|
|
const char *Name;
|
|
|
|
const Value *Value;
|
|
|
|
if (const CallInst *CI = dyn_cast<CallInst>(I)) {
|
|
|
|
Name = "call";
|
|
|
|
Value = CI->getCalledValue();
|
|
|
|
} else if (const InvokeInst* II = dyn_cast<InvokeInst>(I)) {
|
|
|
|
Name = "invoke";
|
|
|
|
Value = II->getCalledValue();
|
|
|
|
} else {
|
|
|
|
// Could demangle more operations, e. g.
|
|
|
|
// `store %place, @function`.
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!Value->hasName()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
StringRef Demangled = CallDemangle(Value->getName());
|
|
|
|
if (Demangled.empty()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
OS << "; " << Name << " " << Demangled << "\n";
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
class RustPrintModulePass : public ModulePass {
|
|
|
|
raw_ostream* OS;
|
|
|
|
DemangleFn Demangle;
|
|
|
|
public:
|
|
|
|
static char ID;
|
|
|
|
RustPrintModulePass() : ModulePass(ID), OS(nullptr), Demangle(nullptr) {}
|
|
|
|
RustPrintModulePass(raw_ostream &OS, DemangleFn Demangle)
|
|
|
|
: ModulePass(ID), OS(&OS), Demangle(Demangle) {}
|
|
|
|
|
|
|
|
bool runOnModule(Module &M) override {
|
|
|
|
RustAssemblyAnnotationWriter AW(Demangle);
|
|
|
|
|
|
|
|
M.print(*OS, &AW, false);
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
void getAnalysisUsage(AnalysisUsage &AU) const override {
|
|
|
|
AU.setPreservesAll();
|
|
|
|
}
|
|
|
|
|
|
|
|
static StringRef name() { return "RustPrintModulePass"; }
|
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace
|
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
void initializeRustPrintModulePassPass(PassRegistry&);
|
|
|
|
}
|
|
|
|
|
|
|
|
char RustPrintModulePass::ID = 0;
|
|
|
|
INITIALIZE_PASS(RustPrintModulePass, "print-rust-module",
|
|
|
|
"Print rust module to stderr", false, false)
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" void LLVMRustPrintModule(LLVMPassManagerRef PMR, LLVMModuleRef M,
|
2017-06-29 09:52:43 -05:00
|
|
|
const char *Path, DemangleFn Demangle) {
|
2016-07-12 17:42:20 -05:00
|
|
|
llvm::legacy::PassManager *PM = unwrap<llvm::legacy::PassManager>(PMR);
|
2013-08-22 22:58:42 -05:00
|
|
|
std::string ErrorInfo;
|
2014-02-26 16:06:27 -06:00
|
|
|
|
2014-09-30 16:20:22 -05:00
|
|
|
std::error_code EC;
|
2016-12-31 11:01:23 -06:00
|
|
|
raw_fd_ostream OS(Path, EC, sys::fs::F_None);
|
2014-09-30 16:20:22 -05:00
|
|
|
if (EC)
|
|
|
|
ErrorInfo = EC.message();
|
2014-02-26 16:06:27 -06:00
|
|
|
|
2013-08-22 22:58:42 -05:00
|
|
|
formatted_raw_ostream FOS(OS);
|
2014-02-26 16:06:27 -06:00
|
|
|
|
2017-06-29 09:52:43 -05:00
|
|
|
PM->add(new RustPrintModulePass(FOS, Demangle));
|
2014-02-26 16:06:27 -06:00
|
|
|
|
2013-08-22 22:58:42 -05:00
|
|
|
PM->run(*unwrap(M));
|
|
|
|
}
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" void LLVMRustPrintPasses() {
|
|
|
|
LLVMInitializePasses();
|
|
|
|
struct MyListener : PassRegistrationListener {
|
2016-12-31 11:01:23 -06:00
|
|
|
void passEnumerate(const PassInfo *Info) {
|
2016-11-27 07:48:47 -06:00
|
|
|
#if LLVM_VERSION_GE(4, 0)
|
2016-12-31 11:01:23 -06:00
|
|
|
StringRef PassArg = Info->getPassArgument();
|
|
|
|
StringRef PassName = Info->getPassName();
|
2016-12-30 05:22:11 -06:00
|
|
|
if (!PassArg.empty()) {
|
|
|
|
// These unsigned->signed casts could theoretically overflow, but
|
|
|
|
// realistically never will (and even if, the result is implementation
|
|
|
|
// defined rather plain UB).
|
|
|
|
printf("%15.*s - %.*s\n", (int)PassArg.size(), PassArg.data(),
|
|
|
|
(int)PassName.size(), PassName.data());
|
|
|
|
}
|
2016-11-27 07:48:47 -06:00
|
|
|
#else
|
2016-12-31 11:01:23 -06:00
|
|
|
if (Info->getPassArgument() && *Info->getPassArgument()) {
|
|
|
|
printf("%15s - %s\n", Info->getPassArgument(), Info->getPassName());
|
2016-12-30 05:22:11 -06:00
|
|
|
}
|
2016-11-27 07:48:47 -06:00
|
|
|
#endif
|
2016-12-30 05:22:11 -06:00
|
|
|
}
|
2016-12-31 11:01:23 -06:00
|
|
|
} Listener;
|
2013-08-22 22:58:42 -05:00
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
PassRegistry *PR = PassRegistry::getPassRegistry();
|
2016-12-31 11:01:23 -06:00
|
|
|
PR->enumerateWith(&Listener);
|
2013-05-27 18:15:31 -05:00
|
|
|
}
|
2013-06-19 17:18:25 -05:00
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
extern "C" void LLVMRustAddAlwaysInlinePass(LLVMPassManagerBuilderRef PMBR,
|
2016-12-30 05:22:11 -06:00
|
|
|
bool AddLifetimes) {
|
2016-09-24 11:37:04 -05:00
|
|
|
#if LLVM_VERSION_GE(4, 0)
|
2016-12-31 11:01:23 -06:00
|
|
|
unwrap(PMBR)->Inliner = llvm::createAlwaysInlinerLegacyPass(AddLifetimes);
|
2016-09-24 11:37:04 -05:00
|
|
|
#else
|
2016-12-31 11:01:23 -06:00
|
|
|
unwrap(PMBR)->Inliner = createAlwaysInlinerPass(AddLifetimes);
|
2016-09-24 11:37:04 -05:00
|
|
|
#endif
|
2013-06-19 17:18:25 -05:00
|
|
|
}
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-03 01:19:29 -06:00
|
|
|
|
2016-12-31 11:01:23 -06:00
|
|
|
extern "C" void LLVMRustRunRestrictionPass(LLVMModuleRef M, char **Symbols,
|
|
|
|
size_t Len) {
|
2016-12-30 05:22:11 -06:00
|
|
|
llvm::legacy::PassManager passes;
|
2016-07-12 17:42:44 -05:00
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
auto PreserveFunctions = [=](const GlobalValue &GV) {
|
2016-12-31 11:01:23 -06:00
|
|
|
for (size_t I = 0; I < Len; I++) {
|
|
|
|
if (GV.getName() == Symbols[I]) {
|
2016-12-30 05:22:11 -06:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
};
|
2016-07-12 17:42:44 -05:00
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
passes.add(llvm::createInternalizePass(PreserveFunctions));
|
2016-07-12 17:42:44 -05:00
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
passes.run(*unwrap(M));
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-03 01:19:29 -06:00
|
|
|
}
|
2013-12-11 01:27:15 -06:00
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" void LLVMRustMarkAllFunctionsNounwind(LLVMModuleRef M) {
|
|
|
|
for (Module::iterator GV = unwrap(M)->begin(), E = unwrap(M)->end(); GV != E;
|
|
|
|
++GV) {
|
|
|
|
GV->setDoesNotThrow();
|
|
|
|
Function *F = dyn_cast<Function>(GV);
|
2016-12-30 06:21:21 -06:00
|
|
|
if (F == nullptr)
|
2016-12-30 05:22:11 -06:00
|
|
|
continue;
|
|
|
|
|
|
|
|
for (Function::iterator B = F->begin(), BE = F->end(); B != BE; ++B) {
|
|
|
|
for (BasicBlock::iterator I = B->begin(), IE = B->end(); I != IE; ++I) {
|
|
|
|
if (isa<InvokeInst>(I)) {
|
|
|
|
InvokeInst *CI = cast<InvokeInst>(I);
|
|
|
|
CI->setDoesNotThrow();
|
2013-12-11 01:27:15 -06:00
|
|
|
}
|
2016-12-30 05:22:11 -06:00
|
|
|
}
|
2013-12-11 01:27:15 -06:00
|
|
|
}
|
2016-12-30 05:22:11 -06:00
|
|
|
}
|
2013-12-11 01:27:15 -06:00
|
|
|
}
|
2015-07-16 17:48:16 -05:00
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
LLVMRustSetDataLayoutFromTargetMachine(LLVMModuleRef Module,
|
|
|
|
LLVMTargetMachineRef TMR) {
|
2016-12-30 05:22:11 -06:00
|
|
|
TargetMachine *Target = unwrap(TMR);
|
|
|
|
unwrap(Module)->setDataLayout(Target->createDataLayout());
|
2015-07-16 17:48:16 -05:00
|
|
|
}
|
|
|
|
|
2016-12-30 05:22:11 -06:00
|
|
|
extern "C" void LLVMRustSetModulePIELevel(LLVMModuleRef M) {
|
|
|
|
unwrap(M)->setPIELevel(PIELevel::Level::Large);
|
2016-07-12 17:41:40 -05:00
|
|
|
}
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
|
|
|
|
extern "C" bool
|
|
|
|
LLVMRustThinLTOAvailable() {
|
|
|
|
#if LLVM_VERSION_GE(4, 0)
|
|
|
|
return true;
|
|
|
|
#else
|
|
|
|
return false;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2018-03-15 10:56:45 -05:00
|
|
|
extern "C" bool
|
|
|
|
LLVMRustPGOAvailable() {
|
|
|
|
#ifdef PGO_AVAILABLE
|
|
|
|
return true;
|
|
|
|
#else
|
|
|
|
return false;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
#if LLVM_VERSION_GE(4, 0)
|
|
|
|
|
|
|
|
// Here you'll find an implementation of ThinLTO as used by the Rust compiler
|
|
|
|
// right now. This ThinLTO support is only enabled on "recent ish" versions of
|
|
|
|
// LLVM, and otherwise it's just blanket rejected from other compilers.
|
|
|
|
//
|
|
|
|
// Most of this implementation is straight copied from LLVM. At the time of
|
|
|
|
// this writing it wasn't *quite* suitable to reuse more code from upstream
|
|
|
|
// for our purposes, but we should strive to upstream this support once it's
|
|
|
|
// ready to go! I figure we may want a bit of testing locally first before
|
|
|
|
// sending this upstream to LLVM. I hear though they're quite eager to receive
|
|
|
|
// feedback like this!
|
|
|
|
//
|
|
|
|
// If you're reading this code and wondering "what in the world" or you're
|
|
|
|
// working "good lord by LLVM upgrade is *still* failing due to these bindings"
|
|
|
|
// then fear not! (ok maybe fear a little). All code here is mostly based
|
|
|
|
// on `lib/LTO/ThinLTOCodeGenerator.cpp` in LLVM.
|
|
|
|
//
|
|
|
|
// You'll find that the general layout here roughly corresponds to the `run`
|
|
|
|
// method in that file as well as `ProcessThinLTOModule`. Functions are
|
|
|
|
// specifically commented below as well, but if you're updating this code
|
|
|
|
// or otherwise trying to understand it, the LLVM source will be useful in
|
|
|
|
// interpreting the mysteries within.
|
|
|
|
//
|
|
|
|
// Otherwise I'll apologize in advance, it probably requires a relatively
|
|
|
|
// significant investment on your part to "truly understand" what's going on
|
|
|
|
// here. Not saying I do myself, but it took me awhile staring at LLVM's source
|
|
|
|
// and various online resources about ThinLTO to make heads or tails of all
|
|
|
|
// this.
|
|
|
|
|
|
|
|
extern "C" bool
|
|
|
|
LLVMRustWriteThinBitcodeToFile(LLVMPassManagerRef PMR,
|
|
|
|
LLVMModuleRef M,
|
|
|
|
const char *BcFile) {
|
|
|
|
llvm::legacy::PassManager *PM = unwrap<llvm::legacy::PassManager>(PMR);
|
|
|
|
std::error_code EC;
|
|
|
|
llvm::raw_fd_ostream bc(BcFile, EC, llvm::sys::fs::F_None);
|
|
|
|
if (EC) {
|
|
|
|
LLVMRustSetLastError(EC.message().c_str());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
PM->add(createWriteThinLTOBitcodePass(bc));
|
|
|
|
PM->run(*unwrap(M));
|
|
|
|
delete PM;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// This is a shared data structure which *must* be threadsafe to share
|
|
|
|
// read-only amongst threads. This also corresponds basically to the arguments
|
|
|
|
// of the `ProcessThinLTOModule` function in the LLVM source.
|
|
|
|
struct LLVMRustThinLTOData {
|
|
|
|
// The combined index that is the global analysis over all modules we're
|
|
|
|
// performing ThinLTO for. This is mostly managed by LLVM.
|
|
|
|
ModuleSummaryIndex Index;
|
|
|
|
|
|
|
|
// All modules we may look at, stored as in-memory serialized versions. This
|
|
|
|
// is later used when inlining to ensure we can extract any module to inline
|
|
|
|
// from.
|
|
|
|
StringMap<MemoryBufferRef> ModuleMap;
|
|
|
|
|
|
|
|
// A set that we manage of everything we *don't* want internalized. Note that
|
|
|
|
// this includes all transitive references right now as well, but it may not
|
|
|
|
// always!
|
|
|
|
DenseSet<GlobalValue::GUID> GUIDPreservedSymbols;
|
|
|
|
|
|
|
|
// Not 100% sure what these are, but they impact what's internalized and
|
|
|
|
// what's inlined across modules, I believe.
|
|
|
|
StringMap<FunctionImporter::ImportMapTy> ImportLists;
|
|
|
|
StringMap<FunctionImporter::ExportSetTy> ExportLists;
|
|
|
|
StringMap<GVSummaryMapTy> ModuleToDefinedGVSummaries;
|
2018-01-30 13:53:18 -06:00
|
|
|
|
|
|
|
#if LLVM_VERSION_GE(7, 0)
|
|
|
|
LLVMRustThinLTOData() : Index(/* isPerformingAnalysis = */ false) {}
|
|
|
|
#endif
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
};
|
|
|
|
|
|
|
|
// Just an argument to the `LLVMRustCreateThinLTOData` function below.
|
|
|
|
struct LLVMRustThinLTOModule {
|
|
|
|
const char *identifier;
|
|
|
|
const char *data;
|
|
|
|
size_t len;
|
|
|
|
};
|
|
|
|
|
|
|
|
// This is copied from `lib/LTO/ThinLTOCodeGenerator.cpp`, not sure what it
|
|
|
|
// does.
|
|
|
|
static const GlobalValueSummary *
|
|
|
|
getFirstDefinitionForLinker(const GlobalValueSummaryList &GVSummaryList) {
|
|
|
|
auto StrongDefForLinker = llvm::find_if(
|
|
|
|
GVSummaryList, [](const std::unique_ptr<GlobalValueSummary> &Summary) {
|
|
|
|
auto Linkage = Summary->linkage();
|
|
|
|
return !GlobalValue::isAvailableExternallyLinkage(Linkage) &&
|
|
|
|
!GlobalValue::isWeakForLinker(Linkage);
|
|
|
|
});
|
|
|
|
if (StrongDefForLinker != GVSummaryList.end())
|
|
|
|
return StrongDefForLinker->get();
|
|
|
|
|
|
|
|
auto FirstDefForLinker = llvm::find_if(
|
|
|
|
GVSummaryList, [](const std::unique_ptr<GlobalValueSummary> &Summary) {
|
|
|
|
auto Linkage = Summary->linkage();
|
|
|
|
return !GlobalValue::isAvailableExternallyLinkage(Linkage);
|
|
|
|
});
|
|
|
|
if (FirstDefForLinker == GVSummaryList.end())
|
|
|
|
return nullptr;
|
|
|
|
return FirstDefForLinker->get();
|
|
|
|
}
|
|
|
|
|
|
|
|
// The main entry point for creating the global ThinLTO analysis. The structure
|
|
|
|
// here is basically the same as before threads are spawned in the `run`
|
|
|
|
// function of `lib/LTO/ThinLTOCodeGenerator.cpp`.
|
|
|
|
extern "C" LLVMRustThinLTOData*
|
|
|
|
LLVMRustCreateThinLTOData(LLVMRustThinLTOModule *modules,
|
|
|
|
int num_modules,
|
|
|
|
const char **preserved_symbols,
|
|
|
|
int num_symbols) {
|
|
|
|
auto Ret = llvm::make_unique<LLVMRustThinLTOData>();
|
|
|
|
|
|
|
|
// Load each module's summary and merge it into one combined index
|
|
|
|
for (int i = 0; i < num_modules; i++) {
|
|
|
|
auto module = &modules[i];
|
|
|
|
StringRef buffer(module->data, module->len);
|
|
|
|
MemoryBufferRef mem_buffer(buffer, module->identifier);
|
|
|
|
|
|
|
|
Ret->ModuleMap[module->identifier] = mem_buffer;
|
|
|
|
|
2017-10-10 14:29:14 -05:00
|
|
|
#if LLVM_VERSION_GE(5, 0)
|
|
|
|
if (Error Err = readModuleSummaryIndex(mem_buffer, Ret->Index, i)) {
|
|
|
|
LLVMRustSetLastError(toString(std::move(Err)).c_str());
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
#else
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
Expected<std::unique_ptr<object::ModuleSummaryIndexObjectFile>> ObjOrErr =
|
|
|
|
object::ModuleSummaryIndexObjectFile::create(mem_buffer);
|
|
|
|
if (!ObjOrErr) {
|
|
|
|
LLVMRustSetLastError(toString(ObjOrErr.takeError()).c_str());
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
auto Index = (*ObjOrErr)->takeIndex();
|
|
|
|
Ret->Index.mergeFrom(std::move(Index), i);
|
2017-10-10 14:29:14 -05:00
|
|
|
#endif
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// Collect for each module the list of function it defines (GUID -> Summary)
|
|
|
|
Ret->Index.collectDefinedGVSummariesPerModule(Ret->ModuleToDefinedGVSummaries);
|
|
|
|
|
|
|
|
// Convert the preserved symbols set from string to GUID, this is then needed
|
2017-11-29 14:00:10 -06:00
|
|
|
// for internalization.
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
for (int i = 0; i < num_symbols; i++) {
|
2017-11-29 14:00:10 -06:00
|
|
|
auto GUID = GlobalValue::getGUID(preserved_symbols[i]);
|
|
|
|
Ret->GUIDPreservedSymbols.insert(GUID);
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// Collect the import/export lists for all modules from the call-graph in the
|
|
|
|
// combined index
|
|
|
|
//
|
|
|
|
// This is copied from `lib/LTO/ThinLTOCodeGenerator.cpp`
|
2017-10-17 00:41:56 -05:00
|
|
|
#if LLVM_VERSION_GE(5, 0)
|
2018-01-30 13:53:18 -06:00
|
|
|
#if LLVM_VERSION_GE(7, 0)
|
|
|
|
auto deadIsPrevailing = [&](GlobalValue::GUID G) {
|
|
|
|
return PrevailingType::Unknown;
|
|
|
|
};
|
|
|
|
computeDeadSymbols(Ret->Index, Ret->GUIDPreservedSymbols, deadIsPrevailing);
|
|
|
|
#else
|
2017-10-17 00:41:56 -05:00
|
|
|
computeDeadSymbols(Ret->Index, Ret->GUIDPreservedSymbols);
|
2018-01-30 13:53:18 -06:00
|
|
|
#endif
|
2017-10-17 00:41:56 -05:00
|
|
|
ComputeCrossModuleImport(
|
|
|
|
Ret->Index,
|
|
|
|
Ret->ModuleToDefinedGVSummaries,
|
|
|
|
Ret->ImportLists,
|
|
|
|
Ret->ExportLists
|
|
|
|
);
|
|
|
|
#else
|
2017-10-11 13:19:59 -05:00
|
|
|
auto DeadSymbols = computeDeadSymbols(Ret->Index, Ret->GUIDPreservedSymbols);
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
ComputeCrossModuleImport(
|
|
|
|
Ret->Index,
|
|
|
|
Ret->ModuleToDefinedGVSummaries,
|
|
|
|
Ret->ImportLists,
|
2017-10-11 13:19:59 -05:00
|
|
|
Ret->ExportLists,
|
|
|
|
&DeadSymbols
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
);
|
2017-10-17 00:41:56 -05:00
|
|
|
#endif
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
|
|
|
|
// Resolve LinkOnce/Weak symbols, this has to be computed early be cause it
|
|
|
|
// impacts the caching.
|
|
|
|
//
|
2017-11-29 14:00:10 -06:00
|
|
|
// This is copied from `lib/LTO/ThinLTOCodeGenerator.cpp` with some of this
|
|
|
|
// being lifted from `lib/LTO/LTO.cpp` as well
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
StringMap<std::map<GlobalValue::GUID, GlobalValue::LinkageTypes>> ResolvedODR;
|
|
|
|
DenseMap<GlobalValue::GUID, const GlobalValueSummary *> PrevailingCopy;
|
|
|
|
for (auto &I : Ret->Index) {
|
2017-10-10 14:29:14 -05:00
|
|
|
#if LLVM_VERSION_GE(5, 0)
|
|
|
|
if (I.second.SummaryList.size() > 1)
|
|
|
|
PrevailingCopy[I.first] = getFirstDefinitionForLinker(I.second.SummaryList);
|
|
|
|
#else
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
if (I.second.size() > 1)
|
|
|
|
PrevailingCopy[I.first] = getFirstDefinitionForLinker(I.second);
|
2017-10-10 14:29:14 -05:00
|
|
|
#endif
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
}
|
|
|
|
auto isPrevailing = [&](GlobalValue::GUID GUID, const GlobalValueSummary *S) {
|
|
|
|
const auto &Prevailing = PrevailingCopy.find(GUID);
|
|
|
|
if (Prevailing == PrevailingCopy.end())
|
|
|
|
return true;
|
|
|
|
return Prevailing->second == S;
|
|
|
|
};
|
|
|
|
auto recordNewLinkage = [&](StringRef ModuleIdentifier,
|
|
|
|
GlobalValue::GUID GUID,
|
|
|
|
GlobalValue::LinkageTypes NewLinkage) {
|
|
|
|
ResolvedODR[ModuleIdentifier][GUID] = NewLinkage;
|
|
|
|
};
|
|
|
|
thinLTOResolveWeakForLinkerInIndex(Ret->Index, isPrevailing, recordNewLinkage);
|
2017-11-29 14:00:10 -06:00
|
|
|
|
|
|
|
// Here we calculate an `ExportedGUIDs` set for use in the `isExported`
|
|
|
|
// callback below. This callback below will dictate the linkage for all
|
|
|
|
// summaries in the index, and we basically just only want to ensure that dead
|
|
|
|
// symbols are internalized. Otherwise everything that's already external
|
|
|
|
// linkage will stay as external, and internal will stay as internal.
|
|
|
|
std::set<GlobalValue::GUID> ExportedGUIDs;
|
|
|
|
for (auto &List : Ret->Index) {
|
2017-12-11 00:52:58 -06:00
|
|
|
#if LLVM_VERSION_GE(5, 0)
|
|
|
|
for (auto &GVS: List.second.SummaryList) {
|
|
|
|
#else
|
2017-11-29 14:00:10 -06:00
|
|
|
for (auto &GVS: List.second) {
|
2017-12-11 00:52:58 -06:00
|
|
|
#endif
|
2017-12-06 19:59:33 -06:00
|
|
|
if (GlobalValue::isLocalLinkage(GVS->linkage()))
|
2017-11-29 14:00:10 -06:00
|
|
|
continue;
|
|
|
|
auto GUID = GVS->getOriginalName();
|
2017-12-11 00:52:58 -06:00
|
|
|
#if LLVM_VERSION_GE(5, 0)
|
|
|
|
if (GVS->flags().Live)
|
|
|
|
#else
|
2017-11-29 14:00:10 -06:00
|
|
|
if (!DeadSymbols.count(GUID))
|
2017-12-11 00:52:58 -06:00
|
|
|
#endif
|
2017-11-29 14:00:10 -06:00
|
|
|
ExportedGUIDs.insert(GUID);
|
|
|
|
}
|
|
|
|
}
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
auto isExported = [&](StringRef ModuleIdentifier, GlobalValue::GUID GUID) {
|
|
|
|
const auto &ExportList = Ret->ExportLists.find(ModuleIdentifier);
|
|
|
|
return (ExportList != Ret->ExportLists.end() &&
|
|
|
|
ExportList->second.count(GUID)) ||
|
2017-11-29 14:00:10 -06:00
|
|
|
ExportedGUIDs.count(GUID);
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
};
|
|
|
|
thinLTOInternalizeAndPromoteInIndex(Ret->Index, isExported);
|
|
|
|
|
|
|
|
return Ret.release();
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
LLVMRustFreeThinLTOData(LLVMRustThinLTOData *Data) {
|
|
|
|
delete Data;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Below are the various passes that happen *per module* when doing ThinLTO.
|
|
|
|
//
|
|
|
|
// In other words, these are the functions that are all run concurrently
|
|
|
|
// with one another, one per module. The passes here correspond to the analysis
|
|
|
|
// passes in `lib/LTO/ThinLTOCodeGenerator.cpp`, currently found in the
|
|
|
|
// `ProcessThinLTOModule` function. Here they're split up into separate steps
|
|
|
|
// so rustc can save off the intermediate bytecode between each step.
|
|
|
|
|
|
|
|
extern "C" bool
|
|
|
|
LLVMRustPrepareThinLTORename(const LLVMRustThinLTOData *Data, LLVMModuleRef M) {
|
|
|
|
Module &Mod = *unwrap(M);
|
|
|
|
if (renameModuleForThinLTO(Mod, Data->Index)) {
|
|
|
|
LLVMRustSetLastError("renameModuleForThinLTO failed");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" bool
|
|
|
|
LLVMRustPrepareThinLTOResolveWeak(const LLVMRustThinLTOData *Data, LLVMModuleRef M) {
|
|
|
|
Module &Mod = *unwrap(M);
|
|
|
|
const auto &DefinedGlobals = Data->ModuleToDefinedGVSummaries.lookup(Mod.getModuleIdentifier());
|
|
|
|
thinLTOResolveWeakForLinkerModule(Mod, DefinedGlobals);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" bool
|
|
|
|
LLVMRustPrepareThinLTOInternalize(const LLVMRustThinLTOData *Data, LLVMModuleRef M) {
|
|
|
|
Module &Mod = *unwrap(M);
|
|
|
|
const auto &DefinedGlobals = Data->ModuleToDefinedGVSummaries.lookup(Mod.getModuleIdentifier());
|
|
|
|
thinLTOInternalizeModule(Mod, DefinedGlobals);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" bool
|
|
|
|
LLVMRustPrepareThinLTOImport(const LLVMRustThinLTOData *Data, LLVMModuleRef M) {
|
|
|
|
Module &Mod = *unwrap(M);
|
|
|
|
const auto &ImportList = Data->ImportLists.lookup(Mod.getModuleIdentifier());
|
|
|
|
auto Loader = [&](StringRef Identifier) {
|
|
|
|
const auto &Memory = Data->ModuleMap.lookup(Identifier);
|
|
|
|
auto &Context = Mod.getContext();
|
|
|
|
return getLazyBitcodeModule(Memory, Context, true, true);
|
|
|
|
};
|
|
|
|
FunctionImporter Importer(Data->Index, Loader);
|
|
|
|
Expected<bool> Result = Importer.importFunctions(Mod, ImportList);
|
|
|
|
if (!Result) {
|
|
|
|
LLVMRustSetLastError(toString(Result.takeError()).c_str());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// This struct and various functions are sort of a hack right now, but the
|
|
|
|
// problem is that we've got in-memory LLVM modules after we generate and
|
|
|
|
// optimize all codegen-units for one compilation in rustc. To be compatible
|
|
|
|
// with the LTO support above we need to serialize the modules plus their
|
|
|
|
// ThinLTO summary into memory.
|
|
|
|
//
|
|
|
|
// This structure is basically an owned version of a serialize module, with
|
|
|
|
// a ThinLTO summary attached.
|
|
|
|
struct LLVMRustThinLTOBuffer {
|
|
|
|
std::string data;
|
|
|
|
};
|
|
|
|
|
|
|
|
extern "C" LLVMRustThinLTOBuffer*
|
|
|
|
LLVMRustThinLTOBufferCreate(LLVMModuleRef M) {
|
|
|
|
auto Ret = llvm::make_unique<LLVMRustThinLTOBuffer>();
|
|
|
|
{
|
|
|
|
raw_string_ostream OS(Ret->data);
|
|
|
|
{
|
|
|
|
legacy::PassManager PM;
|
|
|
|
PM.add(createWriteThinLTOBitcodePass(OS));
|
|
|
|
PM.run(*unwrap(M));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return Ret.release();
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
LLVMRustThinLTOBufferFree(LLVMRustThinLTOBuffer *Buffer) {
|
|
|
|
delete Buffer;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" const void*
|
|
|
|
LLVMRustThinLTOBufferPtr(const LLVMRustThinLTOBuffer *Buffer) {
|
|
|
|
return Buffer->data.data();
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" size_t
|
|
|
|
LLVMRustThinLTOBufferLen(const LLVMRustThinLTOBuffer *Buffer) {
|
|
|
|
return Buffer->data.length();
|
|
|
|
}
|
|
|
|
|
|
|
|
// This is what we used to parse upstream bitcode for actual ThinLTO
|
|
|
|
// processing. We'll call this once per module optimized through ThinLTO, and
|
|
|
|
// it'll be called concurrently on many threads.
|
|
|
|
extern "C" LLVMModuleRef
|
|
|
|
LLVMRustParseBitcodeForThinLTO(LLVMContextRef Context,
|
|
|
|
const char *data,
|
|
|
|
size_t len,
|
|
|
|
const char *identifier) {
|
|
|
|
StringRef Data(data, len);
|
|
|
|
MemoryBufferRef Buffer(Data, identifier);
|
|
|
|
unwrap(Context)->enableDebugTypeODRUniquing();
|
|
|
|
Expected<std::unique_ptr<Module>> SrcOrError =
|
|
|
|
parseBitcodeFile(Buffer, *unwrap(Context));
|
|
|
|
if (!SrcOrError) {
|
|
|
|
LLVMRustSetLastError(toString(SrcOrError.takeError()).c_str());
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
return wrap(std::move(*SrcOrError).release());
|
|
|
|
}
|
|
|
|
|
2017-12-16 10:20:54 -06:00
|
|
|
// Rewrite all `DICompileUnit` pointers to the `DICompileUnit` specified. See
|
|
|
|
// the comment in `back/lto.rs` for why this exists.
|
|
|
|
extern "C" void
|
|
|
|
LLVMRustThinLTOGetDICompileUnit(LLVMModuleRef Mod,
|
|
|
|
DICompileUnit **A,
|
|
|
|
DICompileUnit **B) {
|
|
|
|
Module *M = unwrap(Mod);
|
|
|
|
DICompileUnit **Cur = A;
|
|
|
|
DICompileUnit **Next = B;
|
|
|
|
for (DICompileUnit *CU : M->debug_compile_units()) {
|
|
|
|
*Cur = CU;
|
|
|
|
Cur = Next;
|
|
|
|
Next = nullptr;
|
|
|
|
if (Cur == nullptr)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Rewrite all `DICompileUnit` pointers to the `DICompileUnit` specified. See
|
|
|
|
// the comment in `back/lto.rs` for why this exists.
|
|
|
|
extern "C" void
|
|
|
|
LLVMRustThinLTOPatchDICompileUnit(LLVMModuleRef Mod, DICompileUnit *Unit) {
|
|
|
|
Module *M = unwrap(Mod);
|
|
|
|
|
|
|
|
// If the original source module didn't have a `DICompileUnit` then try to
|
|
|
|
// merge all the existing compile units. If there aren't actually any though
|
|
|
|
// then there's not much for us to do so return.
|
|
|
|
if (Unit == nullptr) {
|
|
|
|
for (DICompileUnit *CU : M->debug_compile_units()) {
|
|
|
|
Unit = CU;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (Unit == nullptr)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Use LLVM's built-in `DebugInfoFinder` to find a bunch of debuginfo and
|
|
|
|
// process it recursively. Note that we specifically iterate over instructions
|
|
|
|
// to ensure we feed everything into it.
|
|
|
|
DebugInfoFinder Finder;
|
|
|
|
Finder.processModule(*M);
|
|
|
|
for (Function &F : M->functions()) {
|
|
|
|
for (auto &FI : F) {
|
|
|
|
for (Instruction &BI : FI) {
|
|
|
|
if (auto Loc = BI.getDebugLoc())
|
|
|
|
Finder.processLocation(*M, Loc);
|
|
|
|
if (auto DVI = dyn_cast<DbgValueInst>(&BI))
|
|
|
|
Finder.processValue(*M, DVI);
|
|
|
|
if (auto DDI = dyn_cast<DbgDeclareInst>(&BI))
|
|
|
|
Finder.processDeclare(*M, DDI);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// After we've found all our debuginfo, rewrite all subprograms to point to
|
|
|
|
// the same `DICompileUnit`.
|
|
|
|
for (auto &F : Finder.subprograms()) {
|
|
|
|
F->replaceUnit(Unit);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Erase any other references to other `DICompileUnit` instances, the verifier
|
|
|
|
// will later ensure that we don't actually have any other stale references to
|
|
|
|
// worry about.
|
|
|
|
auto *MD = M->getNamedMetadata("llvm.dbg.cu");
|
|
|
|
MD->clearOperands();
|
|
|
|
MD->addOperand(Unit);
|
|
|
|
}
|
|
|
|
|
2017-12-21 09:03:16 -06:00
|
|
|
extern "C" void
|
|
|
|
LLVMRustThinLTORemoveAvailableExternally(LLVMModuleRef Mod) {
|
|
|
|
Module *M = unwrap(Mod);
|
|
|
|
for (Function &F : M->functions()) {
|
|
|
|
if (F.hasAvailableExternallyLinkage())
|
|
|
|
F.deleteBody();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
#else
|
|
|
|
|
|
|
|
extern "C" bool
|
|
|
|
LLVMRustWriteThinBitcodeToFile(LLVMPassManagerRef PMR,
|
|
|
|
LLVMModuleRef M,
|
|
|
|
const char *BcFile) {
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("ThinLTO not available");
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
struct LLVMRustThinLTOData {
|
|
|
|
};
|
|
|
|
|
|
|
|
struct LLVMRustThinLTOModule {
|
|
|
|
};
|
|
|
|
|
|
|
|
extern "C" LLVMRustThinLTOData*
|
|
|
|
LLVMRustCreateThinLTOData(LLVMRustThinLTOModule *modules,
|
|
|
|
int num_modules,
|
|
|
|
const char **preserved_symbols,
|
|
|
|
int num_symbols) {
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("ThinLTO not available");
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" bool
|
|
|
|
LLVMRustPrepareThinLTORename(const LLVMRustThinLTOData *Data, LLVMModuleRef M) {
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("ThinLTO not available");
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" bool
|
|
|
|
LLVMRustPrepareThinLTOResolveWeak(const LLVMRustThinLTOData *Data, LLVMModuleRef M) {
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("ThinLTO not available");
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" bool
|
|
|
|
LLVMRustPrepareThinLTOInternalize(const LLVMRustThinLTOData *Data, LLVMModuleRef M) {
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("ThinLTO not available");
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" bool
|
|
|
|
LLVMRustPrepareThinLTOImport(const LLVMRustThinLTOData *Data, LLVMModuleRef M) {
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("ThinLTO not available");
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
LLVMRustFreeThinLTOData(LLVMRustThinLTOData *Data) {
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("ThinLTO not available");
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
struct LLVMRustThinLTOBuffer {
|
|
|
|
};
|
|
|
|
|
|
|
|
extern "C" LLVMRustThinLTOBuffer*
|
|
|
|
LLVMRustThinLTOBufferCreate(LLVMModuleRef M) {
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("ThinLTO not available");
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
LLVMRustThinLTOBufferFree(LLVMRustThinLTOBuffer *Buffer) {
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("ThinLTO not available");
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" const void*
|
|
|
|
LLVMRustThinLTOBufferPtr(const LLVMRustThinLTOBuffer *Buffer) {
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("ThinLTO not available");
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" size_t
|
|
|
|
LLVMRustThinLTOBufferLen(const LLVMRustThinLTOBuffer *Buffer) {
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("ThinLTO not available");
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" LLVMModuleRef
|
|
|
|
LLVMRustParseBitcodeForThinLTO(LLVMContextRef Context,
|
|
|
|
const char *data,
|
|
|
|
size_t len,
|
|
|
|
const char *identifier) {
|
2017-11-20 10:47:29 -06:00
|
|
|
report_fatal_error("ThinLTO not available");
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
}
|
2017-12-16 10:20:54 -06:00
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
LLVMRustThinLTOGetDICompileUnit(LLVMModuleRef Mod,
|
|
|
|
DICompileUnit **A,
|
|
|
|
DICompileUnit **B) {
|
|
|
|
report_fatal_error("ThinLTO not available");
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
LLVMRustThinLTOPatchDICompileUnit(LLVMModuleRef Mod) {
|
|
|
|
report_fatal_error("ThinLTO not available");
|
|
|
|
}
|
2017-12-21 09:03:16 -06:00
|
|
|
|
|
|
|
extern "C" void
|
|
|
|
LLVMRustThinLTORemoveAvailableExternally(LLVMModuleRef Mod) {
|
|
|
|
report_fatal_error("ThinLTO not available");
|
|
|
|
}
|
|
|
|
|
rustc: Implement ThinLTO
This commit is an implementation of LLVM's ThinLTO for consumption in rustc
itself. Currently today LTO works by merging all relevant LLVM modules into one
and then running optimization passes. "Thin" LTO operates differently by having
more sharded work and allowing parallelism opportunities between optimizing
codegen units. Further down the road Thin LTO also allows *incremental* LTO
which should enable even faster release builds without compromising on the
performance we have today.
This commit uses a `-Z thinlto` flag to gate whether ThinLTO is enabled. It then
also implements two forms of ThinLTO:
* In one mode we'll *only* perform ThinLTO over the codegen units produced in a
single compilation. That is, we won't load upstream rlibs, but we'll instead
just perform ThinLTO amongst all codegen units produced by the compiler for
the local crate. This is intended to emulate a desired end point where we have
codegen units turned on by default for all crates and ThinLTO allows us to do
this without performance loss.
* In anther mode, like full LTO today, we'll optimize all upstream dependencies
in "thin" mode. Unlike today, however, this LTO step is fully parallelized so
should finish much more quickly.
There's a good bit of comments about what the implementation is doing and where
it came from, but the tl;dr; is that currently most of the support here is
copied from upstream LLVM. This code duplication is done for a number of
reasons:
* Controlling parallelism means we can use the existing jobserver support to
avoid overloading machines.
* We will likely want a slightly different form of incremental caching which
integrates with our own incremental strategy, but this is yet to be
determined.
* This buys us some flexibility about when/where we run ThinLTO, as well as
having it tailored to fit our needs for the time being.
* Finally this allows us to reuse some artifacts such as our `TargetMachine`
creation, where all our options we used today aren't necessarily supported by
upstream LLVM yet.
My hope is that we can get some experience with this copy/paste in tree and then
eventually upstream some work to LLVM itself to avoid the duplication while
still ensuring our needs are met. Otherwise I fear that maintaining these
bindings may be quite costly over the years with LLVM updates!
2017-07-23 10:14:38 -05:00
|
|
|
#endif // LLVM_VERSION_GE(4, 0)
|