2013-08-23 03:58:42 +00:00
|
|
|
#include <stdio.h>
|
|
|
|
|
2023-09-07 13:48:50 +00:00
|
|
|
#include <cstddef>
|
2023-07-13 23:56:29 +00:00
|
|
|
#include <iomanip>
|
2017-11-29 20:00:10 +00:00
|
|
|
#include <set>
|
2024-06-04 14:46:20 +00:00
|
|
|
#include <vector>
|
2017-06-29 14:52:43 +00:00
|
|
|
|
2020-07-26 17:11:30 +00:00
|
|
|
#include "LLVMWrapper.h"
|
2013-05-27 23:15:31 +00:00
|
|
|
|
2020-11-03 21:47:16 +00:00
|
|
|
#include "llvm/Analysis/AliasAnalysis.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 19:10:43 +00:00
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
|
|
|
#include "llvm/Analysis/TargetTransformInfo.h"
|
2024-06-04 14:46:20 +00:00
|
|
|
#include "llvm/Bitcode/BitcodeWriter.h"
|
2023-09-07 09:34:41 +00:00
|
|
|
#include "llvm/CodeGen/CommandFlags.h"
|
2018-12-09 10:20:20 +00:00
|
|
|
#include "llvm/CodeGen/TargetSubtargetInfo.h"
|
2017-06-29 14:52:43 +00:00
|
|
|
#include "llvm/IR/AssemblyAnnotationWriter.h"
|
2024-06-04 14:46:20 +00:00
|
|
|
#include "llvm/IR/AutoUpgrade.h"
|
2018-12-09 10:20:20 +00:00
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
2020-01-05 18:16:58 +00:00
|
|
|
#include "llvm/IR/Verifier.h"
|
2024-06-04 14:46:20 +00:00
|
|
|
#include "llvm/LTO/LTO.h"
|
2023-02-01 20:52:06 +00:00
|
|
|
#include "llvm/MC/TargetRegistry.h"
|
2020-04-23 18:45:55 +00:00
|
|
|
#include "llvm/Object/IRObjectFile.h"
|
2024-06-04 14:46:20 +00:00
|
|
|
#include "llvm/Object/ObjectFile.h"
|
2020-01-05 18:16:58 +00:00
|
|
|
#include "llvm/Passes/PassBuilder.h"
|
2021-11-19 16:01:41 +00:00
|
|
|
#include "llvm/Passes/PassPlugin.h"
|
2020-01-05 18:16:58 +00:00
|
|
|
#include "llvm/Passes/StandardInstrumentations.h"
|
2016-12-30 11:22:11 +00:00
|
|
|
#include "llvm/Support/CBindingWrapping.h"
|
|
|
|
#include "llvm/Support/FileSystem.h"
|
2024-09-17 19:37:45 +00:00
|
|
|
#include "llvm/Support/TimeProfiler.h"
|
2023-02-02 10:09:48 +00:00
|
|
|
#include "llvm/Support/VirtualFileSystem.h"
|
2015-07-16 22:48:16 +00:00
|
|
|
#include "llvm/Target/TargetMachine.h"
|
2024-09-17 19:37:45 +00:00
|
|
|
#include "llvm/TargetParser/Host.h"
|
2016-09-24 16:37:04 +00:00
|
|
|
#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 15:14:38 +00:00
|
|
|
#include "llvm/Transforms/IPO/FunctionImport.h"
|
2022-09-18 19:17:53 +00:00
|
|
|
#include "llvm/Transforms/IPO/Internalize.h"
|
2023-07-11 23:19:42 +00:00
|
|
|
#include "llvm/Transforms/IPO/LowerTypeTests.h"
|
2022-08-16 13:02:45 +00:00
|
|
|
#include "llvm/Transforms/IPO/ThinLTOBitcodeWriter.h"
|
2019-11-18 00:00:00 +00:00
|
|
|
#include "llvm/Transforms/Instrumentation/AddressSanitizer.h"
|
2024-02-01 21:16:30 +00:00
|
|
|
#include "llvm/Transforms/Instrumentation/DataFlowSanitizer.h"
|
2024-09-17 19:37:45 +00:00
|
|
|
#include "llvm/Transforms/Utils/AddDiscriminators.h"
|
|
|
|
#include "llvm/Transforms/Utils/FunctionImportUtils.h"
|
2024-02-13 00:13:09 +00:00
|
|
|
#if LLVM_VERSION_GE(19, 0)
|
|
|
|
#include "llvm/Support/PGOOptions.h"
|
|
|
|
#endif
|
2021-04-05 09:26:48 +00:00
|
|
|
#include "llvm/Transforms/Instrumentation/GCOVProfiler.h"
|
2024-06-04 14:46:20 +00:00
|
|
|
#include "llvm/Transforms/Instrumentation/HWAddressSanitizer.h"
|
2021-04-05 08:45:04 +00:00
|
|
|
#include "llvm/Transforms/Instrumentation/InstrProfiling.h"
|
2019-11-18 00:00:00 +00:00
|
|
|
#include "llvm/Transforms/Instrumentation/MemorySanitizer.h"
|
2024-06-04 14:46:20 +00:00
|
|
|
#include "llvm/Transforms/Instrumentation/ThreadSanitizer.h"
|
|
|
|
#include "llvm/Transforms/Utils.h"
|
2020-01-05 18:16:58 +00:00
|
|
|
#include "llvm/Transforms/Utils/CanonicalizeAliases.h"
|
|
|
|
#include "llvm/Transforms/Utils/NameAnonGlobals.h"
|
2019-11-18 00:00:00 +00:00
|
|
|
|
2013-08-23 03:58:42 +00:00
|
|
|
using namespace llvm;
|
2013-05-27 23:15:31 +00:00
|
|
|
|
2023-09-07 09:34:41 +00:00
|
|
|
static codegen::RegisterCodeGenFlags CGF;
|
|
|
|
|
2013-08-23 03:58:42 +00:00
|
|
|
typedef struct LLVMOpaquePass *LLVMPassRef;
|
|
|
|
typedef struct LLVMOpaqueTargetMachine *LLVMTargetMachineRef;
|
|
|
|
|
|
|
|
DEFINE_STDCXX_CONVERSION_FUNCTIONS(Pass, LLVMPassRef)
|
|
|
|
DEFINE_STDCXX_CONVERSION_FUNCTIONS(TargetMachine, LLVMTargetMachineRef)
|
2013-05-27 23:15:31 +00:00
|
|
|
|
2023-11-21 18:43:11 +00:00
|
|
|
extern "C" void LLVMRustTimeTraceProfilerInitialize() {
|
2020-02-04 19:35:50 +00:00
|
|
|
timeTraceProfilerInitialize(
|
|
|
|
/* TimeTraceGranularity */ 0,
|
|
|
|
/* ProcName */ "rustc");
|
2020-01-31 23:58:28 +00:00
|
|
|
}
|
|
|
|
|
2023-11-21 18:43:11 +00:00
|
|
|
extern "C" void LLVMRustTimeTraceProfilerFinishThread() {
|
2021-11-05 00:00:00 +00:00
|
|
|
timeTraceProfilerFinishThread();
|
|
|
|
}
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
extern "C" void LLVMRustTimeTraceProfilerFinish(const char *FileName) {
|
2024-03-06 04:04:24 +00:00
|
|
|
auto FN = StringRef(FileName);
|
2020-01-31 23:58:28 +00:00
|
|
|
std::error_code EC;
|
2024-03-06 04:04:24 +00:00
|
|
|
auto OS = raw_fd_ostream(FN, EC, sys::fs::CD_CreateAlways);
|
2020-01-31 23:58:28 +00:00
|
|
|
|
|
|
|
timeTraceProfilerWrite(OS);
|
|
|
|
timeTraceProfilerCleanup();
|
|
|
|
}
|
|
|
|
|
2016-02-16 16:07:30 +00: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
|
|
|
|
|
2016-05-06 13:32:10 +00:00
|
|
|
#ifdef LLVM_COMPONENT_AVR
|
|
|
|
#define SUBTARGET_AVR SUBTARGET(AVR)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_AVR
|
|
|
|
#endif
|
|
|
|
|
2021-08-25 07:49:17 +00:00
|
|
|
#ifdef LLVM_COMPONENT_M68k
|
|
|
|
#define SUBTARGET_M68K SUBTARGET(M68k)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_M68K
|
|
|
|
#endif
|
|
|
|
|
2023-07-13 14:19:59 +00:00
|
|
|
#ifdef LLVM_COMPONENT_CSKY
|
|
|
|
#define SUBTARGET_CSKY SUBTARGET(CSKY)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_CSKY
|
|
|
|
#endif
|
|
|
|
|
2016-02-16 16:07:30 +00:00
|
|
|
#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 18:18:28 +00:00
|
|
|
#ifdef LLVM_COMPONENT_SYSTEMZ
|
|
|
|
#define SUBTARGET_SYSTEMZ SUBTARGET(SystemZ)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_SYSTEMZ
|
|
|
|
#endif
|
|
|
|
|
2016-11-09 21:56:10 +00:00
|
|
|
#ifdef LLVM_COMPONENT_MSP430
|
|
|
|
#define SUBTARGET_MSP430 SUBTARGET(MSP430)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_MSP430
|
|
|
|
#endif
|
|
|
|
|
2018-07-24 10:03:28 +00:00
|
|
|
#ifdef LLVM_COMPONENT_RISCV
|
|
|
|
#define SUBTARGET_RISCV SUBTARGET(RISCV)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_RISCV
|
|
|
|
#endif
|
|
|
|
|
2016-12-03 16:53:31 +00:00
|
|
|
#ifdef LLVM_COMPONENT_SPARC
|
|
|
|
#define SUBTARGET_SPARC SUBTARGET(Sparc)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_SPARC
|
|
|
|
#endif
|
|
|
|
|
2020-09-12 22:20:14 +00:00
|
|
|
#ifdef LLVM_COMPONENT_XTENSA
|
|
|
|
#define SUBTARGET_XTENSA SUBTARGET(XTENSA)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_XTENSA
|
|
|
|
#endif
|
|
|
|
|
2017-04-09 06:03:31 +00:00
|
|
|
#ifdef LLVM_COMPONENT_HEXAGON
|
|
|
|
#define SUBTARGET_HEXAGON SUBTARGET(Hexagon)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_HEXAGON
|
|
|
|
#endif
|
|
|
|
|
2022-07-07 07:46:10 +00:00
|
|
|
#ifdef LLVM_COMPONENT_LOONGARCH
|
|
|
|
#define SUBTARGET_LOONGARCH SUBTARGET(LoongArch)
|
|
|
|
#else
|
|
|
|
#define SUBTARGET_LOONGARCH
|
|
|
|
#endif
|
|
|
|
|
2016-12-30 11:22:11 +00:00
|
|
|
#define GEN_SUBTARGETS \
|
|
|
|
SUBTARGET_X86 \
|
|
|
|
SUBTARGET_ARM \
|
|
|
|
SUBTARGET_AARCH64 \
|
2016-05-06 13:32:10 +00:00
|
|
|
SUBTARGET_AVR \
|
2021-08-25 07:49:17 +00:00
|
|
|
SUBTARGET_M68K \
|
2023-07-13 14:19:59 +00:00
|
|
|
SUBTARGET_CSKY \
|
2016-12-30 11:22:11 +00:00
|
|
|
SUBTARGET_MIPS \
|
|
|
|
SUBTARGET_PPC \
|
|
|
|
SUBTARGET_SYSTEMZ \
|
2017-01-01 03:40:10 +00:00
|
|
|
SUBTARGET_MSP430 \
|
2017-04-09 06:03:31 +00:00
|
|
|
SUBTARGET_SPARC \
|
2018-07-24 10:03:28 +00:00
|
|
|
SUBTARGET_HEXAGON \
|
2020-09-12 22:20:14 +00:00
|
|
|
SUBTARGET_XTENSA \
|
2018-07-24 10:03:28 +00:00
|
|
|
SUBTARGET_RISCV \
|
2024-06-04 14:46:20 +00:00
|
|
|
SUBTARGET_LOONGARCH
|
2016-12-30 11:22:11 +00:00
|
|
|
|
|
|
|
#define SUBTARGET(x) \
|
|
|
|
namespace llvm { \
|
|
|
|
extern const SubtargetFeatureKV x##FeatureKV[]; \
|
|
|
|
extern const SubtargetFeatureKV x##SubTypeKV[]; \
|
2016-02-16 16:07:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
GEN_SUBTARGETS
|
|
|
|
#undef SUBTARGET
|
|
|
|
|
2016-12-30 11:22:11 +00:00
|
|
|
extern "C" bool LLVMRustHasFeature(LLVMTargetMachineRef TM,
|
2016-12-31 17:01:23 +00:00
|
|
|
const char *Feature) {
|
2016-12-30 11:22:11 +00:00
|
|
|
TargetMachine *Target = unwrap(TM);
|
|
|
|
const MCSubtargetInfo *MCInfo = Target->getMCSubtargetInfo();
|
2018-03-27 19:27:45 +00:00
|
|
|
return MCInfo->checkFeatures(std::string("+") + Feature);
|
2016-02-16 16:07:30 +00:00
|
|
|
}
|
|
|
|
|
2016-08-01 21:16:16 +00:00
|
|
|
enum class LLVMRustCodeModel {
|
2020-05-07 00:34:27 +00:00
|
|
|
Tiny,
|
2016-12-30 11:22:11 +00:00
|
|
|
Small,
|
|
|
|
Kernel,
|
|
|
|
Medium,
|
|
|
|
Large,
|
2018-01-23 01:01:36 +00:00
|
|
|
None,
|
2016-08-01 21:16:16 +00:00
|
|
|
};
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
static std::optional<CodeModel::Model> fromRust(LLVMRustCodeModel Model) {
|
2016-12-31 17:01:23 +00:00
|
|
|
switch (Model) {
|
2020-05-07 00:34:27 +00:00
|
|
|
case LLVMRustCodeModel::Tiny:
|
|
|
|
return CodeModel::Tiny;
|
2016-12-30 11:22:11 +00: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;
|
2020-05-07 00:34:27 +00:00
|
|
|
case LLVMRustCodeModel::None:
|
2022-12-11 09:14:50 +00:00
|
|
|
return std::nullopt;
|
2016-12-30 11:22:11 +00:00
|
|
|
default:
|
2017-11-20 16:47:29 +00:00
|
|
|
report_fatal_error("Bad CodeModel.");
|
2016-08-01 21:16:16 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
enum class LLVMRustCodeGenOptLevel {
|
2016-12-30 11:22:11 +00:00
|
|
|
None,
|
|
|
|
Less,
|
|
|
|
Default,
|
|
|
|
Aggressive,
|
2016-08-01 21:16:16 +00:00
|
|
|
};
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
using CodeGenOptLevelEnum = llvm::CodeGenOptLevel;
|
2023-09-15 14:31:43 +00:00
|
|
|
|
|
|
|
static CodeGenOptLevelEnum fromRust(LLVMRustCodeGenOptLevel Level) {
|
2016-12-31 17:01:23 +00:00
|
|
|
switch (Level) {
|
2016-12-30 11:22:11 +00:00
|
|
|
case LLVMRustCodeGenOptLevel::None:
|
2023-09-15 14:31:43 +00:00
|
|
|
return CodeGenOptLevelEnum::None;
|
2016-12-30 11:22:11 +00:00
|
|
|
case LLVMRustCodeGenOptLevel::Less:
|
2023-09-15 14:31:43 +00:00
|
|
|
return CodeGenOptLevelEnum::Less;
|
2016-12-30 11:22:11 +00:00
|
|
|
case LLVMRustCodeGenOptLevel::Default:
|
2023-09-15 14:31:43 +00:00
|
|
|
return CodeGenOptLevelEnum::Default;
|
2016-12-30 11:22:11 +00:00
|
|
|
case LLVMRustCodeGenOptLevel::Aggressive:
|
2023-09-15 14:31:43 +00:00
|
|
|
return CodeGenOptLevelEnum::Aggressive;
|
2016-12-30 11:22:11 +00:00
|
|
|
default:
|
2017-11-20 16:47:29 +00:00
|
|
|
report_fatal_error("Bad CodeGenOptLevel.");
|
2016-08-01 21:16:16 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-01-05 18:16:58 +00:00
|
|
|
enum class LLVMRustPassBuilderOptLevel {
|
|
|
|
O0,
|
|
|
|
O1,
|
|
|
|
O2,
|
|
|
|
O3,
|
|
|
|
Os,
|
|
|
|
Oz,
|
|
|
|
};
|
|
|
|
|
2021-08-05 16:13:58 +00:00
|
|
|
static OptimizationLevel fromRust(LLVMRustPassBuilderOptLevel Level) {
|
2020-01-05 18:16:58 +00:00
|
|
|
switch (Level) {
|
|
|
|
case LLVMRustPassBuilderOptLevel::O0:
|
2021-08-05 16:13:58 +00:00
|
|
|
return OptimizationLevel::O0;
|
2020-01-05 18:16:58 +00:00
|
|
|
case LLVMRustPassBuilderOptLevel::O1:
|
2021-08-05 16:13:58 +00:00
|
|
|
return OptimizationLevel::O1;
|
2020-01-05 18:16:58 +00:00
|
|
|
case LLVMRustPassBuilderOptLevel::O2:
|
2021-08-05 16:13:58 +00:00
|
|
|
return OptimizationLevel::O2;
|
2020-01-05 18:16:58 +00:00
|
|
|
case LLVMRustPassBuilderOptLevel::O3:
|
2021-08-05 16:13:58 +00:00
|
|
|
return OptimizationLevel::O3;
|
2020-01-05 18:16:58 +00:00
|
|
|
case LLVMRustPassBuilderOptLevel::Os:
|
2021-08-05 16:13:58 +00:00
|
|
|
return OptimizationLevel::Os;
|
2020-01-05 18:16:58 +00:00
|
|
|
case LLVMRustPassBuilderOptLevel::Oz:
|
2021-08-05 16:13:58 +00:00
|
|
|
return OptimizationLevel::Oz;
|
2020-01-05 18:16:58 +00:00
|
|
|
default:
|
|
|
|
report_fatal_error("Bad PassBuilderOptLevel.");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-23 17:49:00 +00:00
|
|
|
enum class LLVMRustRelocModel {
|
2017-04-28 22:21:59 +00:00
|
|
|
Static,
|
|
|
|
PIC,
|
|
|
|
DynamicNoPic,
|
|
|
|
ROPI,
|
|
|
|
RWPI,
|
|
|
|
ROPIRWPI,
|
|
|
|
};
|
|
|
|
|
2020-04-23 17:49:00 +00:00
|
|
|
static Reloc::Model fromRust(LLVMRustRelocModel RustReloc) {
|
2017-04-28 22:21:59 +00:00
|
|
|
switch (RustReloc) {
|
2020-04-23 17:49:00 +00:00
|
|
|
case LLVMRustRelocModel::Static:
|
2017-04-28 22:21:59 +00:00
|
|
|
return Reloc::Static;
|
2020-04-23 17:49:00 +00:00
|
|
|
case LLVMRustRelocModel::PIC:
|
2017-04-28 22:21:59 +00:00
|
|
|
return Reloc::PIC_;
|
2020-04-23 17:49:00 +00:00
|
|
|
case LLVMRustRelocModel::DynamicNoPic:
|
2017-04-28 22:21:59 +00:00
|
|
|
return Reloc::DynamicNoPIC;
|
2020-04-23 17:49:00 +00:00
|
|
|
case LLVMRustRelocModel::ROPI:
|
2017-04-28 22:21:59 +00:00
|
|
|
return Reloc::ROPI;
|
2020-04-23 17:49:00 +00:00
|
|
|
case LLVMRustRelocModel::RWPI:
|
2017-04-28 22:21:59 +00:00
|
|
|
return Reloc::RWPI;
|
2020-04-23 17:49:00 +00:00
|
|
|
case LLVMRustRelocModel::ROPIRWPI:
|
2017-04-28 22:21:59 +00:00
|
|
|
return Reloc::ROPI_RWPI;
|
|
|
|
}
|
2017-11-20 16:47:29 +00:00
|
|
|
report_fatal_error("Bad RelocModel.");
|
2017-04-28 22:21:59 +00:00
|
|
|
}
|
|
|
|
|
2016-07-10 14:22:13 +00:00
|
|
|
/// getLongestEntryLength - Return the length of the longest entry in the table.
|
2024-06-04 14:46:20 +00:00
|
|
|
template <typename KV> static size_t getLongestEntryLength(ArrayRef<KV> Table) {
|
2016-07-10 14:22:13 +00:00
|
|
|
size_t MaxLen = 0;
|
|
|
|
for (auto &I : Table)
|
|
|
|
MaxLen = std::max(MaxLen, std::strlen(I.Key));
|
|
|
|
return MaxLen;
|
|
|
|
}
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
using PrintBackendInfo = void(void *, const char *Data, size_t Len);
|
2023-07-13 23:56:29 +00:00
|
|
|
|
|
|
|
extern "C" void LLVMRustPrintTargetCPUs(LLVMTargetMachineRef TM,
|
2024-06-04 14:46:20 +00:00
|
|
|
const char *TargetCPU,
|
|
|
|
PrintBackendInfo Print, void *Out) {
|
2016-12-30 11:22:11 +00:00
|
|
|
const TargetMachine *Target = unwrap(TM);
|
2024-06-04 14:46:20 +00:00
|
|
|
const Triple::ArchType HostArch =
|
|
|
|
Triple(sys::getDefaultTargetTriple()).getArch();
|
2017-09-08 01:07:16 +00:00
|
|
|
const Triple::ArchType TargetArch = Target->getTargetTriple().getArch();
|
2023-05-06 00:27:59 +00:00
|
|
|
|
2023-07-13 23:56:29 +00:00
|
|
|
std::ostringstream Buf;
|
|
|
|
|
2023-08-21 22:27:08 +00:00
|
|
|
const MCSubtargetInfo *MCInfo = Target->getMCSubtargetInfo();
|
2024-06-04 14:46:20 +00:00
|
|
|
const ArrayRef<SubtargetSubTypeKV> CPUTable =
|
|
|
|
MCInfo->getAllProcessorDescriptions();
|
2016-12-30 11:22:11 +00:00
|
|
|
unsigned MaxCPULen = getLongestEntryLength(CPUTable);
|
|
|
|
|
2023-07-13 23:56:29 +00:00
|
|
|
Buf << "Available CPUs for this target:\n";
|
2023-04-22 02:29:32 +00:00
|
|
|
// Don't print the "native" entry when the user specifies --target with a
|
|
|
|
// different arch since that could be wrong or misleading.
|
2017-09-08 01:07:16 +00:00
|
|
|
if (HostArch == TargetArch) {
|
2024-06-04 14:46:20 +00:00
|
|
|
MaxCPULen = std::max(MaxCPULen, (unsigned)std::strlen("native"));
|
2017-09-08 01:07:16 +00:00
|
|
|
const StringRef HostCPU = sys::getHostCPUName();
|
2023-07-13 23:56:29 +00:00
|
|
|
Buf << " " << std::left << std::setw(MaxCPULen) << "native"
|
|
|
|
<< " - Select the CPU of the current host "
|
2024-06-04 14:46:20 +00:00
|
|
|
"(currently "
|
|
|
|
<< HostCPU.str() << ").\n";
|
2017-09-08 01:07:16 +00:00
|
|
|
}
|
2023-04-28 21:23:40 +00:00
|
|
|
for (auto &CPU : CPUTable) {
|
|
|
|
// Compare cpu against current target to label the default
|
|
|
|
if (strcmp(CPU.Key, TargetCPU) == 0) {
|
2023-07-13 23:56:29 +00:00
|
|
|
Buf << " " << std::left << std::setw(MaxCPULen) << CPU.Key
|
|
|
|
<< " - This is the default target CPU for the current build target "
|
2024-06-04 14:46:20 +00:00
|
|
|
"(currently "
|
|
|
|
<< Target->getTargetTriple().str() << ").";
|
|
|
|
} else {
|
2023-07-13 23:56:29 +00:00
|
|
|
Buf << " " << CPU.Key;
|
2023-04-27 01:11:14 +00:00
|
|
|
}
|
2023-07-13 23:56:29 +00:00
|
|
|
Buf << "\n";
|
2023-04-28 21:23:40 +00:00
|
|
|
}
|
2023-07-13 23:56:29 +00:00
|
|
|
|
|
|
|
const auto &BufString = Buf.str();
|
|
|
|
Print(Out, BufString.data(), BufString.size());
|
2016-07-10 14:22:13 +00:00
|
|
|
}
|
|
|
|
|
2021-04-08 05:00:47 +00:00
|
|
|
extern "C" size_t LLVMRustGetTargetFeaturesCount(LLVMTargetMachineRef TM) {
|
2016-12-30 11:22:11 +00:00
|
|
|
const TargetMachine *Target = unwrap(TM);
|
|
|
|
const MCSubtargetInfo *MCInfo = Target->getMCSubtargetInfo();
|
2024-06-04 14:46:20 +00:00
|
|
|
const ArrayRef<SubtargetFeatureKV> FeatTable =
|
|
|
|
MCInfo->getAllProcessorFeatures();
|
2021-04-08 05:00:47 +00:00
|
|
|
return FeatTable.size();
|
|
|
|
}
|
2016-12-30 11:22:11 +00:00
|
|
|
|
2021-04-08 05:00:47 +00:00
|
|
|
extern "C" void LLVMRustGetTargetFeature(LLVMTargetMachineRef TM, size_t Index,
|
2024-06-04 14:46:20 +00:00
|
|
|
const char **Feature,
|
|
|
|
const char **Desc) {
|
2021-04-08 05:00:47 +00:00
|
|
|
const TargetMachine *Target = unwrap(TM);
|
|
|
|
const MCSubtargetInfo *MCInfo = Target->getMCSubtargetInfo();
|
2024-06-04 14:46:20 +00:00
|
|
|
const ArrayRef<SubtargetFeatureKV> FeatTable =
|
|
|
|
MCInfo->getAllProcessorFeatures();
|
2021-04-08 05:00:47 +00:00
|
|
|
const SubtargetFeatureKV Feat = FeatTable[Index];
|
|
|
|
*Feature = Feat.Key;
|
|
|
|
*Desc = Feat.Desc;
|
2023-05-06 00:27:59 +00:00
|
|
|
}
|
2016-07-24 09:49:10 +00:00
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
extern "C" const char *LLVMRustGetHostCPUName(size_t *len) {
|
2018-08-23 18:03:22 +00:00
|
|
|
StringRef Name = sys::getHostCPUName();
|
|
|
|
*len = Name.size();
|
|
|
|
return Name.data();
|
|
|
|
}
|
|
|
|
|
2016-12-30 11:22:11 +00:00
|
|
|
extern "C" LLVMTargetMachineRef LLVMRustCreateTargetMachine(
|
2016-12-31 17:01:23 +00:00
|
|
|
const char *TripleStr, const char *CPU, const char *Feature,
|
2020-04-23 17:49:00 +00:00
|
|
|
const char *ABIStr, LLVMRustCodeModel RustCM, LLVMRustRelocModel RustReloc,
|
2016-12-31 17:01:23 +00:00
|
|
|
LLVMRustCodeGenOptLevel RustOptLevel, bool UseSoftFloat,
|
2024-06-04 14:46:20 +00:00
|
|
|
bool FunctionSections, bool DataSections, bool UniqueSectionNames,
|
2024-06-21 19:08:49 +00:00
|
|
|
bool TrapUnreachable, bool Singlethread, bool VerboseAsm,
|
2024-06-04 14:46:20 +00:00
|
|
|
bool EmitStackSizeSection, bool RelaxELFRelocations, bool UseInitArray,
|
|
|
|
const char *SplitDwarfFile, const char *OutputObjFile,
|
|
|
|
const char *DebugInfoCompression, bool UseEmulatedTls,
|
2023-07-03 11:11:27 +00:00
|
|
|
const char *ArgsCstrBuff, size_t ArgsCstrBuffLen) {
|
2016-07-24 20:31:16 +00:00
|
|
|
|
2016-12-31 17:01:23 +00:00
|
|
|
auto OptLevel = fromRust(RustOptLevel);
|
2017-04-28 22:21:59 +00:00
|
|
|
auto RM = fromRust(RustReloc);
|
2020-05-07 00:34:27 +00:00
|
|
|
auto CM = fromRust(RustCM);
|
2016-07-24 20:31:16 +00:00
|
|
|
|
2016-12-30 11:22:11 +00:00
|
|
|
std::string Error;
|
2024-03-06 04:04:24 +00:00
|
|
|
auto Trip = Triple(Triple::normalize(TripleStr));
|
2016-12-30 11:22:11 +00:00
|
|
|
const llvm::Target *TheTarget =
|
|
|
|
TargetRegistry::lookupTarget(Trip.getTriple(), Error);
|
2016-12-30 12:21:21 +00:00
|
|
|
if (TheTarget == nullptr) {
|
2016-12-30 11:22:11 +00:00
|
|
|
LLVMRustSetLastError(Error.c_str());
|
2016-12-30 12:21:21 +00:00
|
|
|
return nullptr;
|
2016-12-30 11:22:11 +00:00
|
|
|
}
|
2013-08-23 03:58:42 +00:00
|
|
|
|
2023-09-07 09:36:21 +00:00
|
|
|
TargetOptions Options = codegen::InitTargetOptionsFromCodeGenFlags(Trip);
|
2016-07-12 22:41:40 +00:00
|
|
|
|
2016-12-30 11:22:11 +00:00
|
|
|
Options.FloatABIType = FloatABI::Default;
|
|
|
|
if (UseSoftFloat) {
|
|
|
|
Options.FloatABIType = FloatABI::Soft;
|
|
|
|
}
|
|
|
|
Options.DataSections = DataSections;
|
|
|
|
Options.FunctionSections = FunctionSections;
|
2021-10-11 19:09:32 +00:00
|
|
|
Options.UniqueSectionNames = UniqueSectionNames;
|
2024-06-21 19:08:49 +00:00
|
|
|
Options.MCOptions.AsmVerbose = VerboseAsm;
|
2024-06-21 19:01:15 +00:00
|
|
|
// Always preserve comments that were written by the user
|
|
|
|
Options.MCOptions.PreserveAsmComments = true;
|
2019-10-30 04:12:05 +00:00
|
|
|
Options.MCOptions.ABIName = ABIStr;
|
2020-09-23 15:25:20 +00:00
|
|
|
if (SplitDwarfFile) {
|
2024-06-04 14:46:20 +00:00
|
|
|
Options.MCOptions.SplitDwarfFile = SplitDwarfFile;
|
2020-09-23 15:25:20 +00:00
|
|
|
}
|
2023-09-09 12:00:24 +00:00
|
|
|
if (OutputObjFile) {
|
2024-06-04 14:46:20 +00:00
|
|
|
Options.ObjectFilenameForDebug = OutputObjFile;
|
2023-09-09 12:00:24 +00:00
|
|
|
}
|
2024-06-04 14:46:20 +00:00
|
|
|
if (!strcmp("zlib", DebugInfoCompression) &&
|
|
|
|
llvm::compression::zlib::isAvailable()) {
|
2024-03-07 14:49:15 +00:00
|
|
|
#if LLVM_VERSION_GE(19, 0)
|
|
|
|
Options.MCOptions.CompressDebugSections = DebugCompressionType::Zlib;
|
|
|
|
#else
|
2023-07-12 21:07:34 +00:00
|
|
|
Options.CompressDebugSections = DebugCompressionType::Zlib;
|
2024-03-07 14:49:15 +00:00
|
|
|
#endif
|
2024-06-04 14:46:20 +00:00
|
|
|
} else if (!strcmp("zstd", DebugInfoCompression) &&
|
|
|
|
llvm::compression::zstd::isAvailable()) {
|
2024-03-07 14:49:15 +00:00
|
|
|
#if LLVM_VERSION_GE(19, 0)
|
|
|
|
Options.MCOptions.CompressDebugSections = DebugCompressionType::Zstd;
|
|
|
|
#else
|
2023-07-12 21:07:34 +00:00
|
|
|
Options.CompressDebugSections = DebugCompressionType::Zstd;
|
2024-03-07 14:49:15 +00:00
|
|
|
#endif
|
2023-07-12 21:07:34 +00:00
|
|
|
} else if (!strcmp("none", DebugInfoCompression)) {
|
2024-03-07 14:49:15 +00:00
|
|
|
#if LLVM_VERSION_GE(19, 0)
|
|
|
|
Options.MCOptions.CompressDebugSections = DebugCompressionType::None;
|
|
|
|
#else
|
2023-07-12 21:07:34 +00:00
|
|
|
Options.CompressDebugSections = DebugCompressionType::None;
|
2024-03-07 14:49:15 +00:00
|
|
|
#endif
|
2023-07-12 21:07:34 +00:00
|
|
|
}
|
|
|
|
|
2024-03-07 14:49:15 +00:00
|
|
|
#if LLVM_VERSION_GE(19, 0)
|
|
|
|
Options.MCOptions.X86RelaxRelocations = RelaxELFRelocations;
|
|
|
|
#else
|
2019-12-02 12:22:45 +00:00
|
|
|
Options.RelaxELFRelocations = RelaxELFRelocations;
|
2024-03-07 14:49:15 +00:00
|
|
|
#endif
|
2020-04-17 02:40:11 +00:00
|
|
|
Options.UseInitArray = UseInitArray;
|
2023-11-13 12:48:23 +00:00
|
|
|
Options.EmulatedTLS = UseEmulatedTls;
|
2016-12-30 11:22:11 +00:00
|
|
|
|
2017-11-11 15:08:00 +00:00
|
|
|
if (TrapUnreachable) {
|
2018-05-08 13:10:16 +00:00
|
|
|
// Tell LLVM to codegen `unreachable` into an explicit trap instruction.
|
2017-11-11 15:08:00 +00:00
|
|
|
// 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;
|
2023-04-18 11:24:22 +00:00
|
|
|
// But don't emit traps after other traps or no-returns unnecessarily.
|
|
|
|
// ...except for when targeting WebAssembly, because the NoTrapAfterNoreturn
|
|
|
|
// option causes bugs in the LLVM WebAssembly backend. You should be able to
|
|
|
|
// remove this check when Rust's minimum supported LLVM version is >= 18
|
|
|
|
// https://github.com/llvm/llvm-project/pull/65876
|
|
|
|
if (!Trip.isWasm()) {
|
|
|
|
Options.NoTrapAfterNoreturn = true;
|
|
|
|
}
|
2017-11-11 15:08:00 +00:00
|
|
|
}
|
2017-11-10 19:00:52 +00:00
|
|
|
|
2017-10-23 03:01:00 +00:00
|
|
|
if (Singlethread) {
|
|
|
|
Options.ThreadModel = ThreadModel::Single;
|
|
|
|
}
|
|
|
|
|
2018-09-13 17:43:15 +00:00
|
|
|
Options.EmitStackSizeSection = EmitStackSizeSection;
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
if (ArgsCstrBuff != nullptr) {
|
2024-09-16 20:36:35 +00:00
|
|
|
#if LLVM_VERSION_GE(20, 0)
|
|
|
|
int buffer_offset = 0;
|
|
|
|
assert(ArgsCstrBuff[ArgsCstrBuffLen - 1] == '\0');
|
|
|
|
auto Arg0 = std::string(ArgsCstrBuff);
|
|
|
|
buffer_offset = Arg0.size() + 1;
|
2024-09-17 00:06:50 +00:00
|
|
|
auto ArgsCppStr =
|
|
|
|
std::string(ArgsCstrBuff + buffer_offset, ArgsCstrBuffLen - 1);
|
2024-09-16 20:36:35 +00:00
|
|
|
auto i = 0;
|
|
|
|
while (i != std::string::npos) {
|
|
|
|
i = ArgsCppStr.find('\0', i + 1);
|
|
|
|
if (i != std::string::npos)
|
|
|
|
ArgsCppStr.replace(i, i + 1, " ");
|
|
|
|
}
|
|
|
|
Options.MCOptions.Argv0 = Arg0;
|
|
|
|
Options.MCOptions.CommandlineArgs = ArgsCppStr;
|
|
|
|
#else
|
2023-07-03 11:11:27 +00:00
|
|
|
int buffer_offset = 0;
|
|
|
|
assert(ArgsCstrBuff[ArgsCstrBuffLen - 1] == '\0');
|
|
|
|
|
|
|
|
const size_t arg0_len = std::strlen(ArgsCstrBuff);
|
2024-06-04 14:46:20 +00:00
|
|
|
char *arg0 = new char[arg0_len + 1];
|
2023-07-03 11:11:27 +00:00
|
|
|
memcpy(arg0, ArgsCstrBuff, arg0_len);
|
|
|
|
arg0[arg0_len] = '\0';
|
|
|
|
buffer_offset += arg0_len + 1;
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
const int num_cmd_arg_strings = std::count(
|
|
|
|
&ArgsCstrBuff[buffer_offset], &ArgsCstrBuff[ArgsCstrBuffLen], '\0');
|
2023-07-03 11:11:27 +00:00
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
std::string *cmd_arg_strings = new std::string[num_cmd_arg_strings];
|
|
|
|
for (int i = 0; i < num_cmd_arg_strings; ++i) {
|
2023-07-03 11:11:27 +00:00
|
|
|
assert(buffer_offset < ArgsCstrBuffLen);
|
|
|
|
const int len = std::strlen(ArgsCstrBuff + buffer_offset);
|
|
|
|
cmd_arg_strings[i] = std::string(&ArgsCstrBuff[buffer_offset], len);
|
|
|
|
buffer_offset += len + 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
assert(buffer_offset == ArgsCstrBuffLen);
|
|
|
|
|
|
|
|
Options.MCOptions.Argv0 = arg0;
|
|
|
|
Options.MCOptions.CommandLineArgs =
|
2024-06-04 14:46:20 +00:00
|
|
|
llvm::ArrayRef<std::string>(cmd_arg_strings, num_cmd_arg_strings);
|
2024-09-16 20:36:35 +00:00
|
|
|
#endif
|
2023-07-03 11:11:27 +00:00
|
|
|
}
|
|
|
|
|
2016-12-30 11:22:11 +00:00
|
|
|
TargetMachine *TM = TheTarget->createTargetMachine(
|
2018-08-23 18:03:22 +00:00
|
|
|
Trip.getTriple(), CPU, Feature, Options, RM, CM, OptLevel);
|
2016-12-30 11:22:11 +00:00
|
|
|
return wrap(TM);
|
2013-08-23 03:58:42 +00:00
|
|
|
}
|
|
|
|
|
2016-12-30 11:22:11 +00:00
|
|
|
extern "C" void LLVMRustDisposeTargetMachine(LLVMTargetMachineRef TM) {
|
2024-09-16 20:36:35 +00:00
|
|
|
#if LLVM_VERSION_LT(20, 0)
|
2024-06-04 14:46:20 +00:00
|
|
|
MCTargetOptions &MCOptions = unwrap(TM)->Options.MCOptions;
|
2023-07-03 11:11:27 +00:00
|
|
|
delete[] MCOptions.Argv0;
|
|
|
|
delete[] MCOptions.CommandLineArgs.data();
|
2024-09-16 20:36:35 +00:00
|
|
|
#endif
|
2023-07-03 11:11:27 +00:00
|
|
|
|
2016-12-30 11:22:11 +00:00
|
|
|
delete unwrap(TM);
|
2013-08-23 03:58:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Unfortunately, the LLVM C API doesn't provide a way to create the
|
|
|
|
// TargetLibraryInfo pass, so we use this method to do so.
|
2024-01-12 10:23:04 +00:00
|
|
|
extern "C" void LLVMRustAddLibraryInfo(LLVMPassManagerRef PMR, LLVMModuleRef M,
|
|
|
|
bool DisableSimplifyLibCalls) {
|
2024-03-06 04:04:24 +00:00
|
|
|
auto TargetTriple = Triple(unwrap(M)->getTargetTriple());
|
|
|
|
auto TLII = TargetLibraryInfoImpl(TargetTriple);
|
2024-01-12 10:23:04 +00:00
|
|
|
if (DisableSimplifyLibCalls)
|
|
|
|
TLII.disableAllFunctions();
|
2016-12-31 17:01:23 +00:00
|
|
|
unwrap(PMR)->add(new TargetLibraryInfoWrapperPass(TLII));
|
2013-08-23 03:58:42 +00:00
|
|
|
}
|
|
|
|
|
2016-12-30 11:22:11 +00:00
|
|
|
extern "C" void LLVMRustSetLLVMOptions(int Argc, char **Argv) {
|
|
|
|
// Initializing the command-line options more than once is not allowed. So,
|
2022-11-16 20:34:16 +00:00
|
|
|
// check if they've already been initialized. (This could happen if we're
|
2016-12-30 11:22:11 +00:00
|
|
|
// being called from rustpkg, for example). If the arguments change, then
|
|
|
|
// that's just kinda unfortunate.
|
2016-12-31 17:01:23 +00:00
|
|
|
static bool Initialized = false;
|
|
|
|
if (Initialized)
|
2016-12-30 11:22:11 +00:00
|
|
|
return;
|
2016-12-31 17:01:23 +00:00
|
|
|
Initialized = true;
|
2016-12-30 11:22:11 +00:00
|
|
|
cl::ParseCommandLineOptions(Argc, Argv);
|
2013-08-23 03:58:42 +00:00
|
|
|
}
|
|
|
|
|
2016-08-01 21:16:16 +00:00
|
|
|
enum class LLVMRustFileType {
|
2016-12-30 11:22:11 +00:00
|
|
|
AssemblyFile,
|
|
|
|
ObjectFile,
|
2016-08-01 21:16:16 +00:00
|
|
|
};
|
|
|
|
|
2019-12-31 13:05:34 +00:00
|
|
|
static CodeGenFileType fromRust(LLVMRustFileType Type) {
|
|
|
|
switch (Type) {
|
|
|
|
case LLVMRustFileType::AssemblyFile:
|
2023-09-15 14:31:43 +00:00
|
|
|
return CodeGenFileType::AssemblyFile;
|
2019-12-31 13:05:34 +00:00
|
|
|
case LLVMRustFileType::ObjectFile:
|
2023-09-15 14:31:43 +00:00
|
|
|
return CodeGenFileType::ObjectFile;
|
2019-12-31 13:05:34 +00:00
|
|
|
default:
|
|
|
|
report_fatal_error("Bad FileType.");
|
|
|
|
}
|
|
|
|
}
|
2016-08-01 21:16:16 +00:00
|
|
|
|
|
|
|
extern "C" LLVMRustResult
|
2016-12-30 11:22:11 +00:00
|
|
|
LLVMRustWriteOutputFile(LLVMTargetMachineRef Target, LLVMPassManagerRef PMR,
|
2020-09-23 15:25:20 +00:00
|
|
|
LLVMModuleRef M, const char *Path, const char *DwoPath,
|
2016-12-31 17:01:23 +00:00
|
|
|
LLVMRustFileType RustFileType) {
|
2016-07-12 22:42:20 +00:00
|
|
|
llvm::legacy::PassManager *PM = unwrap<llvm::legacy::PassManager>(PMR);
|
2016-12-31 17:01:23 +00:00
|
|
|
auto FileType = fromRust(RustFileType);
|
2013-08-23 03:58:42 +00:00
|
|
|
|
|
|
|
std::string ErrorInfo;
|
2014-09-30 21:20:22 +00:00
|
|
|
std::error_code EC;
|
2024-03-06 04:04:24 +00:00
|
|
|
auto OS = raw_fd_ostream(Path, EC, sys::fs::OF_None);
|
2014-09-30 21:20:22 +00:00
|
|
|
if (EC)
|
|
|
|
ErrorInfo = EC.message();
|
2013-08-23 03:58:42 +00:00
|
|
|
if (ErrorInfo != "") {
|
2014-04-15 14:25:22 +00:00
|
|
|
LLVMRustSetLastError(ErrorInfo.c_str());
|
2016-08-01 21:16:16 +00:00
|
|
|
return LLVMRustResult::Failure;
|
2013-08-23 03:58:42 +00:00
|
|
|
}
|
|
|
|
|
2024-03-06 04:04:24 +00:00
|
|
|
auto BOS = buffer_ostream(OS);
|
2020-09-23 15:25:20 +00:00
|
|
|
if (DwoPath) {
|
2024-03-06 04:04:24 +00:00
|
|
|
auto DOS = raw_fd_ostream(DwoPath, EC, sys::fs::OF_None);
|
2020-09-23 15:25:20 +00:00
|
|
|
EC.clear();
|
|
|
|
if (EC)
|
2024-06-04 14:46:20 +00:00
|
|
|
ErrorInfo = EC.message();
|
2020-09-23 15:25:20 +00:00
|
|
|
if (ErrorInfo != "") {
|
|
|
|
LLVMRustSetLastError(ErrorInfo.c_str());
|
|
|
|
return LLVMRustResult::Failure;
|
|
|
|
}
|
2024-03-06 04:04:24 +00:00
|
|
|
auto DBOS = buffer_ostream(DOS);
|
2020-09-23 15:25:20 +00:00
|
|
|
unwrap(Target)->addPassesToEmitFile(*PM, BOS, &DBOS, FileType, false);
|
|
|
|
PM->run(*unwrap(M));
|
|
|
|
} else {
|
|
|
|
unwrap(Target)->addPassesToEmitFile(*PM, BOS, nullptr, FileType, false);
|
|
|
|
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 19:10:43 +00:00
|
|
|
|
2015-10-07 22:11:25 +00: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 19:10:43 +00:00
|
|
|
// stream (OS), so the only real safe place to delete this is here? Don't we
|
|
|
|
// wish this was written in Rust?
|
2019-11-25 20:44:26 +00:00
|
|
|
LLVMDisposePassManager(PMR);
|
2016-08-01 21:16:16 +00:00
|
|
|
return LLVMRustResult::Success;
|
2013-08-23 03:58:42 +00:00
|
|
|
}
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
extern "C" typedef void (*LLVMRustSelfProfileBeforePassCallback)(
|
|
|
|
void *, // LlvmSelfProfiler
|
|
|
|
const char *, // pass name
|
|
|
|
const char *); // IR name
|
|
|
|
extern "C" typedef void (*LLVMRustSelfProfileAfterPassCallback)(
|
|
|
|
void *); // LlvmSelfProfiler
|
2020-02-11 21:37:16 +00:00
|
|
|
|
|
|
|
std::string LLVMRustwrappedIrGetName(const llvm::Any &WrappedIr) {
|
2023-04-19 04:54:03 +00:00
|
|
|
if (const auto *Cast = any_cast<const Module *>(&WrappedIr))
|
|
|
|
return (*Cast)->getName().str();
|
|
|
|
if (const auto *Cast = any_cast<const Function *>(&WrappedIr))
|
|
|
|
return (*Cast)->getName().str();
|
|
|
|
if (const auto *Cast = any_cast<const Loop *>(&WrappedIr))
|
|
|
|
return (*Cast)->getName().str();
|
|
|
|
if (const auto *Cast = any_cast<const LazyCallGraph::SCC *>(&WrappedIr))
|
|
|
|
return (*Cast)->getName();
|
2020-02-11 21:37:16 +00:00
|
|
|
return "<UNKNOWN>";
|
|
|
|
}
|
|
|
|
|
|
|
|
void LLVMSelfProfileInitializeCallbacks(
|
2024-06-04 14:46:20 +00:00
|
|
|
PassInstrumentationCallbacks &PIC, void *LlvmSelfProfiler,
|
2020-02-11 21:37:16 +00:00
|
|
|
LLVMRustSelfProfileBeforePassCallback BeforePassCallback,
|
|
|
|
LLVMRustSelfProfileAfterPassCallback AfterPassCallback) {
|
2024-06-04 14:46:20 +00:00
|
|
|
PIC.registerBeforeNonSkippedPassCallback(
|
|
|
|
[LlvmSelfProfiler, BeforePassCallback](StringRef Pass, llvm::Any Ir) {
|
|
|
|
std::string PassName = Pass.str();
|
|
|
|
std::string IrName = LLVMRustwrappedIrGetName(Ir);
|
|
|
|
BeforePassCallback(LlvmSelfProfiler, PassName.c_str(), IrName.c_str());
|
|
|
|
});
|
2020-11-03 21:47:16 +00:00
|
|
|
|
|
|
|
PIC.registerAfterPassCallback(
|
2024-06-04 14:46:20 +00:00
|
|
|
[LlvmSelfProfiler, AfterPassCallback](
|
|
|
|
StringRef Pass, llvm::Any IR, const PreservedAnalyses &Preserved) {
|
2020-11-03 21:47:16 +00:00
|
|
|
AfterPassCallback(LlvmSelfProfiler);
|
|
|
|
});
|
|
|
|
|
|
|
|
PIC.registerAfterPassInvalidatedCallback(
|
2024-06-04 14:46:20 +00:00
|
|
|
[LlvmSelfProfiler,
|
|
|
|
AfterPassCallback](StringRef Pass, const PreservedAnalyses &Preserved) {
|
2020-11-03 21:47:16 +00:00
|
|
|
AfterPassCallback(LlvmSelfProfiler);
|
|
|
|
});
|
2020-02-11 21:37:16 +00:00
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
PIC.registerBeforeAnalysisCallback(
|
|
|
|
[LlvmSelfProfiler, BeforePassCallback](StringRef Pass, llvm::Any Ir) {
|
|
|
|
std::string PassName = Pass.str();
|
|
|
|
std::string IrName = LLVMRustwrappedIrGetName(Ir);
|
|
|
|
BeforePassCallback(LlvmSelfProfiler, PassName.c_str(), IrName.c_str());
|
|
|
|
});
|
2020-02-11 21:37:16 +00:00
|
|
|
|
|
|
|
PIC.registerAfterAnalysisCallback(
|
|
|
|
[LlvmSelfProfiler, AfterPassCallback](StringRef Pass, llvm::Any Ir) {
|
|
|
|
AfterPassCallback(LlvmSelfProfiler);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2020-01-05 18:16:58 +00:00
|
|
|
enum class LLVMRustOptStage {
|
|
|
|
PreLinkNoLTO,
|
|
|
|
PreLinkThinLTO,
|
|
|
|
PreLinkFatLTO,
|
|
|
|
ThinLTO,
|
|
|
|
FatLTO,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct LLVMRustSanitizerOptions {
|
2020-06-14 00:00:00 +00:00
|
|
|
bool SanitizeAddress;
|
|
|
|
bool SanitizeAddressRecover;
|
2023-07-11 23:19:42 +00:00
|
|
|
bool SanitizeCFI;
|
2024-02-01 21:16:30 +00:00
|
|
|
bool SanitizeDataFlow;
|
|
|
|
char **SanitizeDataFlowABIList;
|
|
|
|
size_t SanitizeDataFlowABIListLen;
|
2023-07-11 23:19:42 +00:00
|
|
|
bool SanitizeKCFI;
|
2020-01-05 18:16:58 +00:00
|
|
|
bool SanitizeMemory;
|
2020-06-14 00:00:00 +00:00
|
|
|
bool SanitizeMemoryRecover;
|
2024-06-04 14:46:20 +00:00
|
|
|
int SanitizeMemoryTrackOrigins;
|
2020-01-05 18:16:58 +00:00
|
|
|
bool SanitizeThread;
|
2021-01-23 02:32:38 +00:00
|
|
|
bool SanitizeHWAddress;
|
|
|
|
bool SanitizeHWAddressRecover;
|
2022-09-11 23:36:19 +00:00
|
|
|
bool SanitizeKernelAddress;
|
|
|
|
bool SanitizeKernelAddressRecover;
|
2020-01-05 18:16:58 +00:00
|
|
|
};
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
extern "C" LLVMRustResult LLVMRustOptimize(
|
|
|
|
LLVMModuleRef ModuleRef, LLVMTargetMachineRef TMRef,
|
|
|
|
LLVMRustPassBuilderOptLevel OptLevelRust, LLVMRustOptStage OptStage,
|
|
|
|
bool IsLinkerPluginLTO, bool NoPrepopulatePasses, bool VerifyIR,
|
2024-08-29 10:12:31 +00:00
|
|
|
bool LintIR, bool UseThinLTOBuffers, bool MergeFunctions, bool UnrollLoops,
|
2024-06-04 14:46:20 +00:00
|
|
|
bool SLPVectorize, bool LoopVectorize, bool DisableSimplifyLibCalls,
|
|
|
|
bool EmitLifetimeMarkers, LLVMRustSanitizerOptions *SanitizerOptions,
|
|
|
|
const char *PGOGenPath, const char *PGOUsePath, bool InstrumentCoverage,
|
|
|
|
const char *InstrProfileOutput, bool InstrumentGCOV,
|
2021-05-07 07:41:37 +00:00
|
|
|
const char *PGOSampleUsePath, bool DebugInfoForProfiling,
|
2024-06-04 14:46:20 +00:00
|
|
|
void *LlvmSelfProfiler,
|
2020-02-11 21:37:16 +00:00
|
|
|
LLVMRustSelfProfileBeforePassCallback BeforePassCallback,
|
2021-04-05 13:37:11 +00:00
|
|
|
LLVMRustSelfProfileAfterPassCallback AfterPassCallback,
|
2024-06-04 14:46:20 +00:00
|
|
|
const char *ExtraPasses, size_t ExtraPassesLen, const char *LLVMPlugins,
|
|
|
|
size_t LLVMPluginsLen) {
|
2020-01-05 18:16:58 +00:00
|
|
|
Module *TheModule = unwrap(ModuleRef);
|
|
|
|
TargetMachine *TM = unwrap(TMRef);
|
2021-08-05 16:13:58 +00:00
|
|
|
OptimizationLevel OptLevel = fromRust(OptLevelRust);
|
2020-01-05 18:16:58 +00:00
|
|
|
|
|
|
|
PipelineTuningOptions PTO;
|
|
|
|
PTO.LoopUnrolling = UnrollLoops;
|
|
|
|
PTO.LoopInterleaving = UnrollLoops;
|
|
|
|
PTO.LoopVectorization = LoopVectorize;
|
|
|
|
PTO.SLPVectorization = SLPVectorize;
|
2021-03-11 21:30:49 +00:00
|
|
|
PTO.MergeFunctions = MergeFunctions;
|
2020-01-05 18:16:58 +00:00
|
|
|
|
2020-11-03 21:47:16 +00:00
|
|
|
// FIXME: We may want to expose this as an option.
|
|
|
|
bool DebugPassManager = false;
|
|
|
|
|
2020-01-05 18:16:58 +00:00
|
|
|
PassInstrumentationCallbacks PIC;
|
2022-11-25 11:29:00 +00:00
|
|
|
StandardInstrumentations SI(TheModule->getContext(), DebugPassManager);
|
2020-01-05 18:16:58 +00:00
|
|
|
SI.registerCallbacks(PIC);
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
if (LlvmSelfProfiler) {
|
|
|
|
LLVMSelfProfileInitializeCallbacks(PIC, LlvmSelfProfiler,
|
|
|
|
BeforePassCallback, AfterPassCallback);
|
2020-02-11 21:37:16 +00:00
|
|
|
}
|
|
|
|
|
2022-12-05 12:04:25 +00:00
|
|
|
std::optional<PGOOptions> PGOOpt;
|
2023-02-02 10:09:48 +00:00
|
|
|
auto FS = vfs::getRealFileSystem();
|
2020-01-05 18:16:58 +00:00
|
|
|
if (PGOGenPath) {
|
2021-05-07 07:41:37 +00:00
|
|
|
assert(!PGOUsePath && !PGOSampleUsePath);
|
2024-06-04 14:46:20 +00:00
|
|
|
PGOOpt = PGOOptions(PGOGenPath, "", "", "", FS, PGOOptions::IRInstr,
|
|
|
|
PGOOptions::NoCSAction,
|
2024-02-13 00:13:09 +00:00
|
|
|
#if LLVM_VERSION_GE(19, 0)
|
|
|
|
PGOOptions::ColdFuncOpt::Default,
|
|
|
|
#endif
|
2023-02-02 10:09:48 +00:00
|
|
|
DebugInfoForProfiling);
|
2020-01-05 18:16:58 +00:00
|
|
|
} else if (PGOUsePath) {
|
2021-05-07 07:41:37 +00:00
|
|
|
assert(!PGOSampleUsePath);
|
2024-06-04 14:46:20 +00:00
|
|
|
PGOOpt = PGOOptions(PGOUsePath, "", "", "", FS, PGOOptions::IRUse,
|
|
|
|
PGOOptions::NoCSAction,
|
2024-02-13 00:13:09 +00:00
|
|
|
#if LLVM_VERSION_GE(19, 0)
|
|
|
|
PGOOptions::ColdFuncOpt::Default,
|
|
|
|
#endif
|
2023-02-02 10:09:48 +00:00
|
|
|
DebugInfoForProfiling);
|
2021-05-07 07:41:37 +00:00
|
|
|
} else if (PGOSampleUsePath) {
|
2024-06-04 14:46:20 +00:00
|
|
|
PGOOpt = PGOOptions(PGOSampleUsePath, "", "", "", FS, PGOOptions::SampleUse,
|
|
|
|
PGOOptions::NoCSAction,
|
2024-02-13 00:13:09 +00:00
|
|
|
#if LLVM_VERSION_GE(19, 0)
|
|
|
|
PGOOptions::ColdFuncOpt::Default,
|
|
|
|
#endif
|
2023-02-02 10:09:48 +00:00
|
|
|
DebugInfoForProfiling);
|
2021-05-07 07:41:37 +00:00
|
|
|
} else if (DebugInfoForProfiling) {
|
2024-06-04 14:46:20 +00:00
|
|
|
PGOOpt = PGOOptions("", "", "", "", FS, PGOOptions::NoAction,
|
|
|
|
PGOOptions::NoCSAction,
|
2024-02-13 00:13:09 +00:00
|
|
|
#if LLVM_VERSION_GE(19, 0)
|
|
|
|
PGOOptions::ColdFuncOpt::Default,
|
|
|
|
#endif
|
2023-02-02 10:09:48 +00:00
|
|
|
DebugInfoForProfiling);
|
2020-01-05 18:16:58 +00:00
|
|
|
}
|
|
|
|
|
2024-03-06 04:04:24 +00:00
|
|
|
auto PB = PassBuilder(TM, PTO, PGOOpt, &PIC);
|
2021-05-17 18:12:38 +00:00
|
|
|
LoopAnalysisManager LAM;
|
|
|
|
FunctionAnalysisManager FAM;
|
|
|
|
CGSCCAnalysisManager CGAM;
|
|
|
|
ModuleAnalysisManager MAM;
|
2020-01-05 18:16:58 +00:00
|
|
|
|
2023-10-06 12:04:28 +00:00
|
|
|
if (LLVMPluginsLen) {
|
|
|
|
auto PluginsStr = StringRef(LLVMPlugins, LLVMPluginsLen);
|
|
|
|
SmallVector<StringRef> Plugins;
|
|
|
|
PluginsStr.split(Plugins, ',', -1, false);
|
2024-06-04 14:46:20 +00:00
|
|
|
for (auto PluginPath : Plugins) {
|
2023-10-06 12:04:28 +00:00
|
|
|
auto Plugin = PassPlugin::Load(PluginPath.str());
|
|
|
|
if (!Plugin) {
|
2024-01-05 20:59:11 +00:00
|
|
|
auto Err = Plugin.takeError();
|
|
|
|
auto ErrMsg = llvm::toString(std::move(Err));
|
|
|
|
LLVMRustSetLastError(ErrMsg.c_str());
|
2023-10-06 12:04:28 +00:00
|
|
|
return LLVMRustResult::Failure;
|
|
|
|
}
|
|
|
|
Plugin->registerPassBuilderCallbacks(PB);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-01-05 18:16:58 +00:00
|
|
|
FAM.registerPass([&] { return PB.buildDefaultAAPipeline(); });
|
|
|
|
|
|
|
|
Triple TargetTriple(TheModule->getTargetTriple());
|
2024-06-04 14:46:20 +00:00
|
|
|
std::unique_ptr<TargetLibraryInfoImpl> TLII(
|
|
|
|
new TargetLibraryInfoImpl(TargetTriple));
|
2024-01-12 10:23:04 +00:00
|
|
|
if (DisableSimplifyLibCalls)
|
|
|
|
TLII->disableAllFunctions();
|
2020-01-05 18:16:58 +00:00
|
|
|
FAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
|
|
|
|
|
|
|
|
PB.registerModuleAnalyses(MAM);
|
|
|
|
PB.registerCGSCCAnalyses(CGAM);
|
|
|
|
PB.registerFunctionAnalyses(FAM);
|
|
|
|
PB.registerLoopAnalyses(LAM);
|
|
|
|
PB.crossRegisterProxies(LAM, FAM, CGAM, MAM);
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
// We manually collect pipeline callbacks so we can apply them at O0, where
|
|
|
|
// the PassBuilder does not create a pipeline.
|
2021-08-05 16:13:58 +00:00
|
|
|
std::vector<std::function<void(ModulePassManager &, OptimizationLevel)>>
|
2020-11-03 21:47:16 +00:00
|
|
|
PipelineStartEPCallbacks;
|
2021-08-05 16:13:58 +00:00
|
|
|
std::vector<std::function<void(ModulePassManager &, OptimizationLevel)>>
|
2020-06-26 01:52:41 +00:00
|
|
|
OptimizerLastEPCallbacks;
|
2020-01-05 18:16:58 +00:00
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
if (!IsLinkerPluginLTO && SanitizerOptions && SanitizerOptions->SanitizeCFI &&
|
|
|
|
!NoPrepopulatePasses) {
|
2023-07-11 23:19:42 +00:00
|
|
|
PipelineStartEPCallbacks.push_back(
|
2024-06-04 14:46:20 +00:00
|
|
|
[](ModulePassManager &MPM, OptimizationLevel Level) {
|
|
|
|
MPM.addPass(LowerTypeTestsPass(/*ExportSummary=*/nullptr,
|
|
|
|
/*ImportSummary=*/nullptr,
|
|
|
|
/*DropTypeTests=*/false));
|
|
|
|
});
|
2023-07-11 23:19:42 +00:00
|
|
|
}
|
|
|
|
|
2020-01-05 18:16:58 +00:00
|
|
|
if (VerifyIR) {
|
2020-11-03 21:47:16 +00:00
|
|
|
PipelineStartEPCallbacks.push_back(
|
2024-06-04 14:46:20 +00:00
|
|
|
[VerifyIR](ModulePassManager &MPM, OptimizationLevel Level) {
|
|
|
|
MPM.addPass(VerifierPass());
|
|
|
|
});
|
2020-01-05 18:16:58 +00:00
|
|
|
}
|
|
|
|
|
2024-08-29 10:12:31 +00:00
|
|
|
if (LintIR) {
|
|
|
|
PipelineStartEPCallbacks.push_back(
|
|
|
|
[](ModulePassManager &MPM, OptimizationLevel Level) {
|
|
|
|
MPM.addPass(createModuleToFunctionPassAdaptor(LintPass()));
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2021-04-05 09:26:48 +00:00
|
|
|
if (InstrumentGCOV) {
|
|
|
|
PipelineStartEPCallbacks.push_back(
|
2024-06-04 14:46:20 +00:00
|
|
|
[](ModulePassManager &MPM, OptimizationLevel Level) {
|
|
|
|
MPM.addPass(GCOVProfilerPass(GCOVOptions::getDefault()));
|
|
|
|
});
|
2021-04-05 09:26:48 +00:00
|
|
|
}
|
|
|
|
|
2021-04-05 08:45:04 +00:00
|
|
|
if (InstrumentCoverage) {
|
|
|
|
PipelineStartEPCallbacks.push_back(
|
2024-06-04 14:46:20 +00:00
|
|
|
[InstrProfileOutput](ModulePassManager &MPM, OptimizationLevel Level) {
|
|
|
|
InstrProfOptions Options;
|
|
|
|
if (InstrProfileOutput) {
|
|
|
|
Options.InstrProfileOutput = InstrProfileOutput;
|
|
|
|
}
|
|
|
|
// cargo run tests in multhreading mode by default
|
|
|
|
// so use atomics for coverage counters
|
|
|
|
Options.Atomic = true;
|
|
|
|
MPM.addPass(InstrProfilingLoweringPass(Options, false));
|
|
|
|
});
|
2021-04-05 08:45:04 +00:00
|
|
|
}
|
|
|
|
|
2020-01-05 18:16:58 +00:00
|
|
|
if (SanitizerOptions) {
|
2024-02-01 21:16:30 +00:00
|
|
|
if (SanitizerOptions->SanitizeDataFlow) {
|
|
|
|
std::vector<std::string> ABIListFiles(
|
|
|
|
SanitizerOptions->SanitizeDataFlowABIList,
|
|
|
|
SanitizerOptions->SanitizeDataFlowABIList +
|
|
|
|
SanitizerOptions->SanitizeDataFlowABIListLen);
|
|
|
|
OptimizerLastEPCallbacks.push_back(
|
2024-06-04 14:46:20 +00:00
|
|
|
[ABIListFiles](ModulePassManager &MPM, OptimizationLevel Level) {
|
|
|
|
MPM.addPass(DataFlowSanitizerPass(ABIListFiles));
|
|
|
|
});
|
2024-02-01 21:16:30 +00:00
|
|
|
}
|
|
|
|
|
2020-01-05 18:16:58 +00:00
|
|
|
if (SanitizerOptions->SanitizeMemory) {
|
2022-08-14 09:37:03 +00:00
|
|
|
MemorySanitizerOptions Options(
|
|
|
|
SanitizerOptions->SanitizeMemoryTrackOrigins,
|
|
|
|
SanitizerOptions->SanitizeMemoryRecover,
|
|
|
|
/*CompileKernel=*/false,
|
|
|
|
/*EagerChecks=*/true);
|
2020-06-26 01:52:41 +00:00
|
|
|
OptimizerLastEPCallbacks.push_back(
|
2024-06-04 14:46:20 +00:00
|
|
|
[Options](ModulePassManager &MPM, OptimizationLevel Level) {
|
|
|
|
MPM.addPass(MemorySanitizerPass(Options));
|
|
|
|
});
|
2020-01-05 18:16:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (SanitizerOptions->SanitizeThread) {
|
2024-06-04 14:46:20 +00:00
|
|
|
OptimizerLastEPCallbacks.push_back([](ModulePassManager &MPM,
|
|
|
|
OptimizationLevel Level) {
|
|
|
|
MPM.addPass(ModuleThreadSanitizerPass());
|
|
|
|
MPM.addPass(createModuleToFunctionPassAdaptor(ThreadSanitizerPass()));
|
|
|
|
});
|
2020-01-05 18:16:58 +00:00
|
|
|
}
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
if (SanitizerOptions->SanitizeAddress ||
|
|
|
|
SanitizerOptions->SanitizeKernelAddress) {
|
2020-06-26 01:52:41 +00:00
|
|
|
OptimizerLastEPCallbacks.push_back(
|
2024-06-04 14:46:20 +00:00
|
|
|
[SanitizerOptions](ModulePassManager &MPM, OptimizationLevel Level) {
|
|
|
|
auto CompileKernel = SanitizerOptions->SanitizeKernelAddress;
|
|
|
|
AddressSanitizerOptions opts = AddressSanitizerOptions{
|
|
|
|
CompileKernel,
|
|
|
|
SanitizerOptions->SanitizeAddressRecover ||
|
|
|
|
SanitizerOptions->SanitizeKernelAddressRecover,
|
|
|
|
/*UseAfterScope=*/true,
|
|
|
|
AsanDetectStackUseAfterReturnMode::Runtime,
|
|
|
|
};
|
|
|
|
MPM.addPass(AddressSanitizerPass(opts));
|
|
|
|
});
|
2021-01-23 02:32:38 +00:00
|
|
|
}
|
|
|
|
if (SanitizerOptions->SanitizeHWAddress) {
|
|
|
|
OptimizerLastEPCallbacks.push_back(
|
2024-06-04 14:46:20 +00:00
|
|
|
[SanitizerOptions](ModulePassManager &MPM, OptimizationLevel Level) {
|
|
|
|
HWAddressSanitizerOptions opts(
|
|
|
|
/*CompileKernel=*/false,
|
|
|
|
SanitizerOptions->SanitizeHWAddressRecover,
|
|
|
|
/*DisableOptimization=*/false);
|
|
|
|
MPM.addPass(HWAddressSanitizerPass(opts));
|
|
|
|
});
|
2020-01-05 18:16:58 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-05-17 18:12:38 +00:00
|
|
|
ModulePassManager MPM;
|
2020-11-03 21:47:16 +00:00
|
|
|
bool NeedThinLTOBufferPasses = UseThinLTOBuffers;
|
2020-01-05 18:16:58 +00:00
|
|
|
if (!NoPrepopulatePasses) {
|
2024-06-04 14:46:20 +00:00
|
|
|
// The pre-link pipelines don't support O0 and require using
|
|
|
|
// buildO0DefaultPipeline() instead. At the same time, the LTO pipelines do
|
|
|
|
// support O0 and using them is required.
|
|
|
|
bool IsLTO = OptStage == LLVMRustOptStage::ThinLTO ||
|
|
|
|
OptStage == LLVMRustOptStage::FatLTO;
|
2021-09-13 16:18:59 +00:00
|
|
|
if (OptLevel == OptimizationLevel::O0 && !IsLTO) {
|
2020-01-05 18:16:58 +00:00
|
|
|
for (const auto &C : PipelineStartEPCallbacks)
|
2020-11-03 21:47:16 +00:00
|
|
|
PB.registerPipelineStartEPCallback(C);
|
|
|
|
for (const auto &C : OptimizerLastEPCallbacks)
|
|
|
|
PB.registerOptimizerLastEPCallback(C);
|
2020-01-05 18:16:58 +00:00
|
|
|
|
2020-11-03 21:47:16 +00:00
|
|
|
// Pass false as we manually schedule ThinLTOBufferPasses below.
|
|
|
|
MPM = PB.buildO0DefaultPipeline(OptLevel, /* PreLinkLTO */ false);
|
2020-01-05 18:16:58 +00:00
|
|
|
} else {
|
|
|
|
for (const auto &C : PipelineStartEPCallbacks)
|
|
|
|
PB.registerPipelineStartEPCallback(C);
|
2024-02-06 09:44:40 +00:00
|
|
|
for (const auto &C : OptimizerLastEPCallbacks)
|
|
|
|
PB.registerOptimizerLastEPCallback(C);
|
2020-01-05 18:16:58 +00:00
|
|
|
|
|
|
|
switch (OptStage) {
|
|
|
|
case LLVMRustOptStage::PreLinkNoLTO:
|
|
|
|
MPM = PB.buildPerModuleDefaultPipeline(OptLevel, DebugPassManager);
|
|
|
|
break;
|
|
|
|
case LLVMRustOptStage::PreLinkThinLTO:
|
2020-11-03 21:47:16 +00:00
|
|
|
MPM = PB.buildThinLTOPreLinkDefaultPipeline(OptLevel);
|
2024-01-26 08:36:56 +00:00
|
|
|
NeedThinLTOBufferPasses = false;
|
2020-01-05 18:16:58 +00:00
|
|
|
break;
|
|
|
|
case LLVMRustOptStage::PreLinkFatLTO:
|
2020-11-03 21:47:16 +00:00
|
|
|
MPM = PB.buildLTOPreLinkDefaultPipeline(OptLevel);
|
|
|
|
NeedThinLTOBufferPasses = false;
|
2020-01-05 18:16:58 +00:00
|
|
|
break;
|
|
|
|
case LLVMRustOptStage::ThinLTO:
|
|
|
|
// FIXME: Does it make sense to pass the ModuleSummaryIndex?
|
|
|
|
// It only seems to be needed for C++ specific optimizations.
|
2020-11-03 21:47:16 +00:00
|
|
|
MPM = PB.buildThinLTODefaultPipeline(OptLevel, nullptr);
|
2020-01-05 18:16:58 +00:00
|
|
|
break;
|
|
|
|
case LLVMRustOptStage::FatLTO:
|
2020-11-03 21:47:16 +00:00
|
|
|
MPM = PB.buildLTODefaultPipeline(OptLevel, nullptr);
|
2020-01-05 18:16:58 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2022-04-10 19:30:35 +00:00
|
|
|
} else {
|
|
|
|
// We're not building any of the default pipelines but we still want to
|
|
|
|
// add the verifier, instrumentation, etc passes if they were requested
|
|
|
|
for (const auto &C : PipelineStartEPCallbacks)
|
|
|
|
C(MPM, OptLevel);
|
|
|
|
for (const auto &C : OptimizerLastEPCallbacks)
|
|
|
|
C(MPM, OptLevel);
|
2020-01-05 18:16:58 +00:00
|
|
|
}
|
|
|
|
|
2021-04-05 13:37:11 +00:00
|
|
|
if (ExtraPassesLen) {
|
2024-06-04 14:46:20 +00:00
|
|
|
if (auto Err =
|
|
|
|
PB.parsePassPipeline(MPM, StringRef(ExtraPasses, ExtraPassesLen))) {
|
2021-04-05 13:37:11 +00:00
|
|
|
std::string ErrMsg = toString(std::move(Err));
|
|
|
|
LLVMRustSetLastError(ErrMsg.c_str());
|
|
|
|
return LLVMRustResult::Failure;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-11-03 21:47:16 +00:00
|
|
|
if (NeedThinLTOBufferPasses) {
|
2020-01-05 18:16:58 +00:00
|
|
|
MPM.addPass(CanonicalizeAliasesPass());
|
|
|
|
MPM.addPass(NameAnonGlobalPass());
|
|
|
|
}
|
|
|
|
|
|
|
|
// Upgrade all calls to old intrinsics first.
|
|
|
|
for (Module::iterator I = TheModule->begin(), E = TheModule->end(); I != E;)
|
|
|
|
UpgradeCallsToIntrinsic(&*I++); // must be post-increment, as we remove
|
|
|
|
|
|
|
|
MPM.run(*TheModule, MAM);
|
2021-04-05 13:37:11 +00:00
|
|
|
return LLVMRustResult::Success;
|
2020-01-05 18:16:58 +00:00
|
|
|
}
|
2017-06-29 14:52:43 +00: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.
|
2024-06-04 14:46:20 +00:00
|
|
|
typedef size_t (*DemangleFn)(const char *, size_t, char *, size_t);
|
2017-06-29 14:52:43 +00:00
|
|
|
|
|
|
|
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()) {
|
2024-06-04 14:46:20 +00:00
|
|
|
return;
|
2017-06-29 14:52:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
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";
|
2020-06-26 01:52:41 +00:00
|
|
|
Value = CI->getCalledOperand();
|
2024-06-04 14:46:20 +00:00
|
|
|
} else if (const InvokeInst *II = dyn_cast<InvokeInst>(I)) {
|
2017-06-29 14:52:43 +00:00
|
|
|
Name = "invoke";
|
2020-06-26 01:52:41 +00:00
|
|
|
Value = II->getCalledOperand();
|
2017-06-29 14:52:43 +00:00
|
|
|
} 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";
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
extern "C" LLVMRustResult LLVMRustPrintModule(LLVMModuleRef M, const char *Path,
|
|
|
|
DemangleFn Demangle) {
|
2013-08-23 03:58:42 +00:00
|
|
|
std::string ErrorInfo;
|
2014-09-30 21:20:22 +00:00
|
|
|
std::error_code EC;
|
2024-03-06 04:04:24 +00:00
|
|
|
auto OS = raw_fd_ostream(Path, EC, sys::fs::OF_None);
|
2014-09-30 21:20:22 +00:00
|
|
|
if (EC)
|
|
|
|
ErrorInfo = EC.message();
|
2019-04-06 00:48:23 +00:00
|
|
|
if (ErrorInfo != "") {
|
|
|
|
LLVMRustSetLastError(ErrorInfo.c_str());
|
|
|
|
return LLVMRustResult::Failure;
|
|
|
|
}
|
2014-02-26 22:06:27 +00:00
|
|
|
|
2024-03-06 04:04:24 +00:00
|
|
|
auto AAW = RustAssemblyAnnotationWriter(Demangle);
|
|
|
|
auto FOS = formatted_raw_ostream(OS);
|
2019-12-02 09:53:01 +00:00
|
|
|
unwrap(M)->print(FOS, &AAW);
|
2019-04-06 00:48:23 +00:00
|
|
|
|
|
|
|
return LLVMRustResult::Success;
|
2013-08-23 03:58:42 +00:00
|
|
|
}
|
|
|
|
|
2016-12-30 11:22:11 +00:00
|
|
|
extern "C" void LLVMRustPrintPasses() {
|
2023-03-01 08:26:00 +00:00
|
|
|
PassBuilder PB;
|
|
|
|
PB.printPassNames(outs());
|
2013-05-27 23:15:31 +00:00
|
|
|
}
|
2013-06-19 22:18:25 +00:00
|
|
|
|
2016-12-31 17:01:23 +00:00
|
|
|
extern "C" void LLVMRustRunRestrictionPass(LLVMModuleRef M, char **Symbols,
|
|
|
|
size_t Len) {
|
2016-12-30 11:22:11 +00:00
|
|
|
auto PreserveFunctions = [=](const GlobalValue &GV) {
|
2023-08-08 19:47:36 +00:00
|
|
|
// Preserve LLVM-injected, ASAN-related symbols.
|
|
|
|
// See also https://github.com/rust-lang/rust/issues/113404.
|
|
|
|
if (GV.getName() == "___asan_globals_registered") {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Preserve symbols exported from Rust modules.
|
2016-12-31 17:01:23 +00:00
|
|
|
for (size_t I = 0; I < Len; I++) {
|
|
|
|
if (GV.getName() == Symbols[I]) {
|
2016-12-30 11:22:11 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
};
|
2016-07-12 22:42:44 +00:00
|
|
|
|
2022-09-18 19:17:53 +00:00
|
|
|
internalizeModule(*unwrap(M), PreserveFunctions);
|
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 07:19:29 +00:00
|
|
|
}
|
2013-12-11 07:27:15 +00:00
|
|
|
|
2015-07-16 22:48:16 +00:00
|
|
|
extern "C" void
|
|
|
|
LLVMRustSetDataLayoutFromTargetMachine(LLVMModuleRef Module,
|
|
|
|
LLVMTargetMachineRef TMR) {
|
2016-12-30 11:22:11 +00:00
|
|
|
TargetMachine *Target = unwrap(TMR);
|
|
|
|
unwrap(Module)->setDataLayout(Target->createDataLayout());
|
2015-07-16 22:48:16 +00:00
|
|
|
}
|
|
|
|
|
2019-11-03 16:52:00 +00:00
|
|
|
extern "C" void LLVMRustSetModulePICLevel(LLVMModuleRef M) {
|
|
|
|
unwrap(M)->setPICLevel(PICLevel::Level::BigPIC);
|
|
|
|
}
|
|
|
|
|
2016-12-30 11:22:11 +00:00
|
|
|
extern "C" void LLVMRustSetModulePIELevel(LLVMModuleRef M) {
|
|
|
|
unwrap(M)->setPIELevel(PIELevel::Level::Large);
|
2016-07-12 22:41:40 +00: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 15:14:38 +00:00
|
|
|
|
2021-03-11 23:35:13 +00:00
|
|
|
extern "C" void LLVMRustSetModuleCodeModel(LLVMModuleRef M,
|
|
|
|
LLVMRustCodeModel Model) {
|
|
|
|
auto CM = fromRust(Model);
|
2022-09-26 23:51:18 +00:00
|
|
|
if (!CM)
|
2021-03-11 23:35:13 +00:00
|
|
|
return;
|
|
|
|
unwrap(M)->setCodeModel(*CM);
|
|
|
|
}
|
|
|
|
|
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 15:14:38 +00:00
|
|
|
// 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.
|
|
|
|
|
|
|
|
// 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.
|
2024-09-18 13:23:42 +00:00
|
|
|
#if LLVM_VERSION_GE(20, 0)
|
|
|
|
FunctionImporter::ImportListsTy ImportLists;
|
|
|
|
#else
|
2023-08-05 10:53:34 +00:00
|
|
|
DenseMap<StringRef, FunctionImporter::ImportMapTy> ImportLists;
|
2024-09-18 13:23:42 +00:00
|
|
|
#endif
|
2023-08-05 10:53:34 +00:00
|
|
|
DenseMap<StringRef, FunctionImporter::ExportSetTy> ExportLists;
|
|
|
|
DenseMap<StringRef, GVSummaryMapTy> ModuleToDefinedGVSummaries;
|
Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse
During incremental ThinLTO compilation, we attempt to re-use the
optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do
so.
Up until now, 'safe' has meant that the set of modules that our current
modules imports from/exports to is unchanged from the previous
compilation session. See PR #67020 and PR #71131 for more details.
However, this turns out be insufficient to guarantee that it's safe
to reuse the post-LTO module (i.e. that optimizing the pre-LTO module
would produce the same result). When LLVM optimizes a module during
ThinLTO, it may look at other information from the 'module index', such
as whether a (non-imported!) global variable is used. If this
information changes between compilation runs, we may end up re-using an
optimized module that (for example) had dead-code elimination run on a
function that is now used by another module.
Fortunately, LLVM implements its own ThinLTO module cache, which is used
when ThinLTO is performed by a linker plugin (e.g. when clang is used to
compile a C proect). Using this cache directly would require extensive
refactoring of our code - but fortunately for us, LLVM provides a
function that does exactly what we need.
The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash
from all data that might influence the result of ThinLTO on a module.
In addition to the module imports/exports that we manually track, it
also hashes information about global variables (e.g. their liveness)
which might be used during optimization. By using this function, we
shouldn't have to worry about new LLVM passes breaking our module re-use
behavior.
In LLVM, the output of this function forms part of the filename used to
store the post-ThinLTO module. To keep our current filename structure
intact, this PR just writes out the mapping 'CGU name -> Hash' to a
file. To determine if a post-LTO module should be reused, we compare
hashes from the previous session.
This should unblock PR #75199 - by sheer chance, it seems to have hit
this issue due to the particular CGU partitioning and optimization
decisions that end up getting made.
2020-09-17 21:36:13 +00:00
|
|
|
StringMap<std::map<GlobalValue::GUID, GlobalValue::LinkageTypes>> ResolvedODR;
|
2018-01-30 19:53:18 +00:00
|
|
|
|
2019-01-16 17:59:03 +00:00
|
|
|
LLVMRustThinLTOData() : Index(/* HaveGVs = */ false) {}
|
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 15:14:38 +00: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`.
|
2024-06-04 14:46:20 +00:00
|
|
|
extern "C" LLVMRustThinLTOData *
|
|
|
|
LLVMRustCreateThinLTOData(LLVMRustThinLTOModule *modules, int num_modules,
|
|
|
|
const char **preserved_symbols, int num_symbols) {
|
2019-12-31 13:08:25 +00:00
|
|
|
auto Ret = std::make_unique<LLVMRustThinLTOData>();
|
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 15:14:38 +00:00
|
|
|
|
|
|
|
// Load each module's summary and merge it into one combined index
|
|
|
|
for (int i = 0; i < num_modules; i++) {
|
|
|
|
auto module = &modules[i];
|
2024-03-06 04:04:24 +00:00
|
|
|
auto buffer = StringRef(module->data, module->len);
|
|
|
|
auto mem_buffer = MemoryBufferRef(buffer, module->identifier);
|
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 15:14:38 +00:00
|
|
|
|
|
|
|
Ret->ModuleMap[module->identifier] = mem_buffer;
|
|
|
|
|
2023-09-05 10:04:25 +00:00
|
|
|
if (Error Err = readModuleSummaryIndex(mem_buffer, Ret->Index)) {
|
2017-10-10 19:29:14 +00:00
|
|
|
LLVMRustSetLastError(toString(std::move(Err)).c_str());
|
|
|
|
return nullptr;
|
|
|
|
}
|
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 15:14:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Collect for each module the list of function it defines (GUID -> Summary)
|
2024-06-04 14:46:20 +00:00
|
|
|
Ret->Index.collectDefinedGVSummariesPerModule(
|
|
|
|
Ret->ModuleToDefinedGVSummaries);
|
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 15:14:38 +00:00
|
|
|
|
|
|
|
// Convert the preserved symbols set from string to GUID, this is then needed
|
2017-11-29 20:00:10 +00: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 15:14:38 +00:00
|
|
|
for (int i = 0; i < num_symbols; i++) {
|
2017-11-29 20:00:10 +00: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 15:14:38 +00: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`
|
2018-01-30 19:53:18 +00:00
|
|
|
auto deadIsPrevailing = [&](GlobalValue::GUID G) {
|
|
|
|
return PrevailingType::Unknown;
|
|
|
|
};
|
2019-04-26 15:58:14 +00:00
|
|
|
// We don't have a complete picture in our use of ThinLTO, just our immediate
|
|
|
|
// crate, so we need `ImportEnabled = false` to limit internalization.
|
|
|
|
// Otherwise, we sometimes lose `static` values -- see #60184.
|
2019-01-16 17:59:03 +00:00
|
|
|
computeDeadSymbolsWithConstProp(Ret->Index, Ret->GUIDPreservedSymbols,
|
2024-06-04 14:46:20 +00:00
|
|
|
deadIsPrevailing,
|
|
|
|
/* ImportEnabled = */ false);
|
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 15:14:38 +00:00
|
|
|
// Resolve LinkOnce/Weak symbols, this has to be computed early be cause it
|
|
|
|
// impacts the caching.
|
|
|
|
//
|
2017-11-29 20:00:10 +00: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 15:14:38 +00:00
|
|
|
DenseMap<GlobalValue::GUID, const GlobalValueSummary *> PrevailingCopy;
|
|
|
|
for (auto &I : Ret->Index) {
|
2017-10-10 19:29:14 +00:00
|
|
|
if (I.second.SummaryList.size() > 1)
|
2024-06-04 14:46:20 +00:00
|
|
|
PrevailingCopy[I.first] =
|
|
|
|
getFirstDefinitionForLinker(I.second.SummaryList);
|
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 15:14:38 +00: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;
|
|
|
|
};
|
2024-06-04 14:46:20 +00:00
|
|
|
ComputeCrossModuleImport(Ret->Index, Ret->ModuleToDefinedGVSummaries,
|
|
|
|
isPrevailing, Ret->ImportLists, Ret->ExportLists);
|
2023-03-27 11:12:47 +00: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 15:14:38 +00:00
|
|
|
auto recordNewLinkage = [&](StringRef ModuleIdentifier,
|
|
|
|
GlobalValue::GUID GUID,
|
|
|
|
GlobalValue::LinkageTypes NewLinkage) {
|
Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse
During incremental ThinLTO compilation, we attempt to re-use the
optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do
so.
Up until now, 'safe' has meant that the set of modules that our current
modules imports from/exports to is unchanged from the previous
compilation session. See PR #67020 and PR #71131 for more details.
However, this turns out be insufficient to guarantee that it's safe
to reuse the post-LTO module (i.e. that optimizing the pre-LTO module
would produce the same result). When LLVM optimizes a module during
ThinLTO, it may look at other information from the 'module index', such
as whether a (non-imported!) global variable is used. If this
information changes between compilation runs, we may end up re-using an
optimized module that (for example) had dead-code elimination run on a
function that is now used by another module.
Fortunately, LLVM implements its own ThinLTO module cache, which is used
when ThinLTO is performed by a linker plugin (e.g. when clang is used to
compile a C proect). Using this cache directly would require extensive
refactoring of our code - but fortunately for us, LLVM provides a
function that does exactly what we need.
The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash
from all data that might influence the result of ThinLTO on a module.
In addition to the module imports/exports that we manually track, it
also hashes information about global variables (e.g. their liveness)
which might be used during optimization. By using this function, we
shouldn't have to worry about new LLVM passes breaking our module re-use
behavior.
In LLVM, the output of this function forms part of the filename used to
store the post-ThinLTO module. To keep our current filename structure
intact, this PR just writes out the mapping 'CGU name -> Hash' to a
file. To determine if a post-LTO module should be reused, we compare
hashes from the previous session.
This should unblock PR #75199 - by sheer chance, it seems to have hit
this issue due to the particular CGU partitioning and optimization
decisions that end up getting made.
2020-09-17 21:36:13 +00:00
|
|
|
Ret->ResolvedODR[ModuleIdentifier][GUID] = NewLinkage;
|
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 15:14:38 +00:00
|
|
|
};
|
2020-11-07 22:25:45 +00:00
|
|
|
|
2021-03-22 18:37:49 +00:00
|
|
|
// Uses FromPrevailing visibility scheme which works for many binary
|
|
|
|
// formats. We probably could and should use ELF visibility scheme for many of
|
|
|
|
// our targets, however.
|
2021-03-16 20:45:21 +00:00
|
|
|
lto::Config conf;
|
2024-06-04 14:46:20 +00:00
|
|
|
thinLTOResolvePrevailingInIndex(conf, Ret->Index, isPrevailing,
|
|
|
|
recordNewLinkage, Ret->GUIDPreservedSymbols);
|
2022-08-12 17:22:38 +00:00
|
|
|
|
2017-11-29 20:00:10 +00: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) {
|
2024-06-04 14:46:20 +00:00
|
|
|
for (auto &GVS : List.second.SummaryList) {
|
2017-12-07 01:59:33 +00:00
|
|
|
if (GlobalValue::isLocalLinkage(GVS->linkage()))
|
2017-11-29 20:00:10 +00:00
|
|
|
continue;
|
|
|
|
auto GUID = GVS->getOriginalName();
|
2017-12-11 06:52:58 +00:00
|
|
|
if (GVS->flags().Live)
|
2017-11-29 20:00:10 +00:00
|
|
|
ExportedGUIDs.insert(GUID);
|
|
|
|
}
|
|
|
|
}
|
2019-12-31 13:14:31 +00:00
|
|
|
auto isExported = [&](StringRef ModuleIdentifier, ValueInfo VI) {
|
|
|
|
const auto &ExportList = Ret->ExportLists.find(ModuleIdentifier);
|
|
|
|
return (ExportList != Ret->ExportLists.end() &&
|
2024-06-04 14:46:20 +00:00
|
|
|
ExportList->second.count(VI)) ||
|
|
|
|
ExportedGUIDs.count(VI.getGUID());
|
2019-12-31 13:14:31 +00:00
|
|
|
};
|
|
|
|
thinLTOInternalizeAndPromoteInIndex(Ret->Index, isExported, isPrevailing);
|
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 15:14:38 +00:00
|
|
|
|
|
|
|
return Ret.release();
|
|
|
|
}
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
extern "C" void LLVMRustFreeThinLTOData(LLVMRustThinLTOData *Data) {
|
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 15:14:38 +00:00
|
|
|
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.
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
static bool clearDSOLocalOnDeclarations(Module &Mod, TargetMachine &TM) {
|
2020-06-26 01:52:41 +00:00
|
|
|
// When linking an ELF shared object, dso_local should be dropped. We
|
|
|
|
// conservatively do this for -fpic.
|
2024-06-04 14:46:20 +00:00
|
|
|
bool ClearDSOLocalOnDeclarations = TM.getTargetTriple().isOSBinFormatELF() &&
|
|
|
|
TM.getRelocationModel() != Reloc::Static &&
|
|
|
|
Mod.getPIELevel() == PIELevel::Default;
|
2020-06-26 01:52:41 +00:00
|
|
|
return ClearDSOLocalOnDeclarations;
|
|
|
|
}
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
extern "C" bool LLVMRustPrepareThinLTORename(const LLVMRustThinLTOData *Data,
|
|
|
|
LLVMModuleRef M,
|
|
|
|
LLVMTargetMachineRef TM) {
|
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 15:14:38 +00:00
|
|
|
Module &Mod = *unwrap(M);
|
2020-06-26 01:52:41 +00:00
|
|
|
TargetMachine &Target = *unwrap(TM);
|
|
|
|
|
|
|
|
bool ClearDSOLocal = clearDSOLocalOnDeclarations(Mod, Target);
|
|
|
|
bool error = renameModuleForThinLTO(Mod, Data->Index, ClearDSOLocal);
|
|
|
|
|
|
|
|
if (error) {
|
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 15:14:38 +00:00
|
|
|
LLVMRustSetLastError("renameModuleForThinLTO failed");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" bool
|
2024-06-04 14:46:20 +00:00
|
|
|
LLVMRustPrepareThinLTOResolveWeak(const LLVMRustThinLTOData *Data,
|
|
|
|
LLVMModuleRef M) {
|
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 15:14:38 +00:00
|
|
|
Module &Mod = *unwrap(M);
|
2024-06-04 14:46:20 +00:00
|
|
|
const auto &DefinedGlobals =
|
|
|
|
Data->ModuleToDefinedGVSummaries.lookup(Mod.getModuleIdentifier());
|
2021-09-27 21:03:08 +00:00
|
|
|
thinLTOFinalizeInModule(Mod, DefinedGlobals, /*PropagateAttrs=*/true);
|
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 15:14:38 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" bool
|
2024-06-04 14:46:20 +00:00
|
|
|
LLVMRustPrepareThinLTOInternalize(const LLVMRustThinLTOData *Data,
|
|
|
|
LLVMModuleRef M) {
|
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 15:14:38 +00:00
|
|
|
Module &Mod = *unwrap(M);
|
2024-06-04 14:46:20 +00:00
|
|
|
const auto &DefinedGlobals =
|
|
|
|
Data->ModuleToDefinedGVSummaries.lookup(Mod.getModuleIdentifier());
|
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 15:14:38 +00:00
|
|
|
thinLTOInternalizeModule(Mod, DefinedGlobals);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2024-09-17 00:11:02 +00:00
|
|
|
extern "C" bool LLVMRustPrepareThinLTOImport(const LLVMRustThinLTOData *Data,
|
2024-06-04 14:46:20 +00:00
|
|
|
LLVMModuleRef M,
|
|
|
|
LLVMTargetMachineRef TM) {
|
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 15:14:38 +00:00
|
|
|
Module &Mod = *unwrap(M);
|
2020-06-26 01:52:41 +00:00
|
|
|
TargetMachine &Target = *unwrap(TM);
|
2018-07-18 19:12:53 +00:00
|
|
|
|
2024-09-17 00:11:02 +00:00
|
|
|
const auto &ImportList = Data->ImportLists.lookup(Mod.getModuleIdentifier());
|
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 15:14:38 +00:00
|
|
|
auto Loader = [&](StringRef Identifier) {
|
|
|
|
const auto &Memory = Data->ModuleMap.lookup(Identifier);
|
|
|
|
auto &Context = Mod.getContext();
|
2018-07-18 19:12:53 +00:00
|
|
|
auto MOrErr = getLazyBitcodeModule(Memory, Context, true, true);
|
|
|
|
|
|
|
|
if (!MOrErr)
|
2018-07-29 11:20:06 +00:00
|
|
|
return MOrErr;
|
2018-07-18 19:12:53 +00:00
|
|
|
|
|
|
|
// The rest of this closure is a workaround for
|
|
|
|
// https://bugs.llvm.org/show_bug.cgi?id=38184 where during ThinLTO imports
|
|
|
|
// we accidentally import wasm custom sections into different modules,
|
|
|
|
// duplicating them by in the final output artifact.
|
|
|
|
//
|
|
|
|
// The issue is worked around here by manually removing the
|
|
|
|
// `wasm.custom_sections` named metadata node from any imported module. This
|
|
|
|
// we know isn't used by any optimization pass so there's no need for it to
|
|
|
|
// be imported.
|
|
|
|
//
|
|
|
|
// Note that the metadata is currently lazily loaded, so we materialize it
|
|
|
|
// here before looking up if there's metadata inside. The `FunctionImporter`
|
|
|
|
// will immediately materialize metadata anyway after an import, so this
|
|
|
|
// shouldn't be a perf hit.
|
|
|
|
if (Error Err = (*MOrErr)->materializeMetadata()) {
|
|
|
|
Expected<std::unique_ptr<Module>> Ret(std::move(Err));
|
2018-07-29 11:20:06 +00:00
|
|
|
return Ret;
|
2018-07-18 19:12:53 +00:00
|
|
|
}
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
auto *WasmCustomSections =
|
|
|
|
(*MOrErr)->getNamedMetadata("wasm.custom_sections");
|
2018-07-18 19:12:53 +00:00
|
|
|
if (WasmCustomSections)
|
|
|
|
WasmCustomSections->eraseFromParent();
|
|
|
|
|
2022-05-28 23:10:44 +00:00
|
|
|
// `llvm.ident` named metadata also gets duplicated.
|
|
|
|
auto *llvmIdent = (*MOrErr)->getNamedMetadata("llvm.ident");
|
|
|
|
if (llvmIdent)
|
|
|
|
llvmIdent->eraseFromParent();
|
|
|
|
|
2018-07-29 11:20:06 +00:00
|
|
|
return MOrErr;
|
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 15:14:38 +00:00
|
|
|
};
|
2020-06-26 01:52:41 +00:00
|
|
|
bool ClearDSOLocal = clearDSOLocalOnDeclarations(Mod, Target);
|
2024-03-06 04:04:24 +00:00
|
|
|
auto Importer = FunctionImporter(Data->Index, Loader, ClearDSOLocal);
|
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 15:14:38 +00:00
|
|
|
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;
|
2024-01-19 19:42:43 +00:00
|
|
|
std::string thin_link_data;
|
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 15:14:38 +00:00
|
|
|
};
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
extern "C" LLVMRustThinLTOBuffer *
|
2024-05-23 18:58:30 +00:00
|
|
|
LLVMRustThinLTOBufferCreate(LLVMModuleRef M, bool is_thin, bool emit_summary) {
|
2019-12-31 13:08:25 +00:00
|
|
|
auto Ret = std::make_unique<LLVMRustThinLTOBuffer>();
|
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 15:14:38 +00:00
|
|
|
{
|
2024-03-06 04:04:24 +00:00
|
|
|
auto OS = raw_string_ostream(Ret->data);
|
2024-01-19 19:42:43 +00:00
|
|
|
auto ThinLinkOS = raw_string_ostream(Ret->thin_link_data);
|
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 15:14:38 +00:00
|
|
|
{
|
2022-06-08 14:30:16 +00:00
|
|
|
if (is_thin) {
|
2022-08-16 13:02:45 +00:00
|
|
|
PassBuilder PB;
|
|
|
|
LoopAnalysisManager LAM;
|
|
|
|
FunctionAnalysisManager FAM;
|
|
|
|
CGSCCAnalysisManager CGAM;
|
|
|
|
ModuleAnalysisManager MAM;
|
|
|
|
PB.registerModuleAnalyses(MAM);
|
|
|
|
PB.registerCGSCCAnalyses(CGAM);
|
|
|
|
PB.registerFunctionAnalyses(FAM);
|
|
|
|
PB.registerLoopAnalyses(LAM);
|
|
|
|
PB.crossRegisterProxies(LAM, FAM, CGAM, MAM);
|
|
|
|
ModulePassManager MPM;
|
2024-05-23 18:58:30 +00:00
|
|
|
// We only pass ThinLinkOS to be filled in if we want the summary,
|
|
|
|
// because otherwise LLVM does extra work and may double-emit some
|
|
|
|
// errors or warnings.
|
2024-06-04 14:46:20 +00:00
|
|
|
MPM.addPass(
|
|
|
|
ThinLTOBitcodeWriterPass(OS, emit_summary ? &ThinLinkOS : nullptr));
|
2022-08-16 13:02:45 +00:00
|
|
|
MPM.run(*unwrap(M), MAM);
|
2022-06-08 14:30:16 +00:00
|
|
|
} else {
|
2022-09-18 18:53:38 +00:00
|
|
|
WriteBitcodeToFile(*unwrap(M), OS);
|
2022-06-08 14:30:16 +00: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 15:14:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return Ret.release();
|
|
|
|
}
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
extern "C" void LLVMRustThinLTOBufferFree(LLVMRustThinLTOBuffer *Buffer) {
|
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 15:14:38 +00:00
|
|
|
delete Buffer;
|
|
|
|
}
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
extern "C" const void *
|
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 15:14:38 +00:00
|
|
|
LLVMRustThinLTOBufferPtr(const LLVMRustThinLTOBuffer *Buffer) {
|
|
|
|
return Buffer->data.data();
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" size_t
|
|
|
|
LLVMRustThinLTOBufferLen(const LLVMRustThinLTOBuffer *Buffer) {
|
|
|
|
return Buffer->data.length();
|
|
|
|
}
|
|
|
|
|
2024-06-04 14:46:20 +00:00
|
|
|
extern "C" const void *
|
2024-01-19 19:42:43 +00:00
|
|
|
LLVMRustThinLTOBufferThinLinkDataPtr(const LLVMRustThinLTOBuffer *Buffer) {
|
|
|
|
return Buffer->thin_link_data.data();
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" size_t
|
|
|
|
LLVMRustThinLTOBufferThinLinkDataLen(const LLVMRustThinLTOBuffer *Buffer) {
|
|
|
|
return Buffer->thin_link_data.length();
|
|
|
|
}
|
|
|
|
|
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 15:14:38 +00:00
|
|
|
// This is what we used to parse upstream bitcode for actual ThinLTO
|
2022-11-16 20:34:16 +00:00
|
|
|
// processing. We'll call this once per module optimized through ThinLTO, and
|
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 15:14:38 +00:00
|
|
|
// it'll be called concurrently on many threads.
|
2024-06-04 14:46:20 +00:00
|
|
|
extern "C" LLVMModuleRef LLVMRustParseBitcodeForLTO(LLVMContextRef Context,
|
|
|
|
const char *data,
|
|
|
|
size_t len,
|
|
|
|
const char *identifier) {
|
2024-03-06 04:04:24 +00:00
|
|
|
auto Data = StringRef(data, len);
|
|
|
|
auto Buffer = MemoryBufferRef(Data, identifier);
|
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 15:14:38 +00:00
|
|
|
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());
|
|
|
|
}
|
|
|
|
|
2023-09-07 13:48:50 +00:00
|
|
|
// Find a section of an object file by name. Fail if the section is missing or
|
|
|
|
// empty.
|
|
|
|
extern "C" const char *LLVMRustGetSliceFromObjectDataByName(const char *data,
|
|
|
|
size_t len,
|
|
|
|
const char *name,
|
|
|
|
size_t *out_len) {
|
|
|
|
*out_len = 0;
|
2024-03-06 04:04:24 +00:00
|
|
|
auto Data = StringRef(data, len);
|
|
|
|
auto Buffer = MemoryBufferRef(Data, ""); // The id is unused.
|
2023-09-07 13:48:50 +00:00
|
|
|
file_magic Type = identify_magic(Buffer.getBuffer());
|
|
|
|
Expected<std::unique_ptr<object::ObjectFile>> ObjFileOrError =
|
|
|
|
object::ObjectFile::createObjectFile(Buffer, Type);
|
|
|
|
if (!ObjFileOrError) {
|
|
|
|
LLVMRustSetLastError(toString(ObjFileOrError.takeError()).c_str());
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
for (const object::SectionRef &Sec : (*ObjFileOrError)->sections()) {
|
|
|
|
Expected<StringRef> Name = Sec.getName();
|
|
|
|
if (Name && *Name == name) {
|
|
|
|
Expected<StringRef> SectionOrError = Sec.getContents();
|
|
|
|
if (!SectionOrError) {
|
|
|
|
LLVMRustSetLastError(toString(SectionOrError.takeError()).c_str());
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
*out_len = SectionOrError->size();
|
|
|
|
return SectionOrError->data();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
LLVMRustSetLastError("could not find requested section");
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse
During incremental ThinLTO compilation, we attempt to re-use the
optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do
so.
Up until now, 'safe' has meant that the set of modules that our current
modules imports from/exports to is unchanged from the previous
compilation session. See PR #67020 and PR #71131 for more details.
However, this turns out be insufficient to guarantee that it's safe
to reuse the post-LTO module (i.e. that optimizing the pre-LTO module
would produce the same result). When LLVM optimizes a module during
ThinLTO, it may look at other information from the 'module index', such
as whether a (non-imported!) global variable is used. If this
information changes between compilation runs, we may end up re-using an
optimized module that (for example) had dead-code elimination run on a
function that is now used by another module.
Fortunately, LLVM implements its own ThinLTO module cache, which is used
when ThinLTO is performed by a linker plugin (e.g. when clang is used to
compile a C proect). Using this cache directly would require extensive
refactoring of our code - but fortunately for us, LLVM provides a
function that does exactly what we need.
The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash
from all data that might influence the result of ThinLTO on a module.
In addition to the module imports/exports that we manually track, it
also hashes information about global variables (e.g. their liveness)
which might be used during optimization. By using this function, we
shouldn't have to worry about new LLVM passes breaking our module re-use
behavior.
In LLVM, the output of this function forms part of the filename used to
store the post-ThinLTO module. To keep our current filename structure
intact, this PR just writes out the mapping 'CGU name -> Hash' to a
file. To determine if a post-LTO module should be reused, we compare
hashes from the previous session.
This should unblock PR #75199 - by sheer chance, it seems to have hit
this issue due to the particular CGU partitioning and optimization
decisions that end up getting made.
2020-09-17 21:36:13 +00:00
|
|
|
// Computes the LTO cache key for the provided 'ModId' in the given 'Data',
|
|
|
|
// storing the result in 'KeyOut'.
|
|
|
|
// Currently, this cache key is a SHA-1 hash of anything that could affect
|
|
|
|
// the result of optimizing this module (e.g. module imports, exports, liveness
|
|
|
|
// of access globals, etc).
|
|
|
|
// The precise details are determined by LLVM in `computeLTOCacheKey`, which is
|
|
|
|
// used during the normal linker-plugin incremental thin-LTO process.
|
2024-06-04 14:46:20 +00:00
|
|
|
extern "C" void LLVMRustComputeLTOCacheKey(RustStringRef KeyOut,
|
|
|
|
const char *ModId,
|
|
|
|
LLVMRustThinLTOData *Data) {
|
Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse
During incremental ThinLTO compilation, we attempt to re-use the
optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do
so.
Up until now, 'safe' has meant that the set of modules that our current
modules imports from/exports to is unchanged from the previous
compilation session. See PR #67020 and PR #71131 for more details.
However, this turns out be insufficient to guarantee that it's safe
to reuse the post-LTO module (i.e. that optimizing the pre-LTO module
would produce the same result). When LLVM optimizes a module during
ThinLTO, it may look at other information from the 'module index', such
as whether a (non-imported!) global variable is used. If this
information changes between compilation runs, we may end up re-using an
optimized module that (for example) had dead-code elimination run on a
function that is now used by another module.
Fortunately, LLVM implements its own ThinLTO module cache, which is used
when ThinLTO is performed by a linker plugin (e.g. when clang is used to
compile a C proect). Using this cache directly would require extensive
refactoring of our code - but fortunately for us, LLVM provides a
function that does exactly what we need.
The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash
from all data that might influence the result of ThinLTO on a module.
In addition to the module imports/exports that we manually track, it
also hashes information about global variables (e.g. their liveness)
which might be used during optimization. By using this function, we
shouldn't have to worry about new LLVM passes breaking our module re-use
behavior.
In LLVM, the output of this function forms part of the filename used to
store the post-ThinLTO module. To keep our current filename structure
intact, this PR just writes out the mapping 'CGU name -> Hash' to a
file. To determine if a post-LTO module should be reused, we compare
hashes from the previous session.
This should unblock PR #75199 - by sheer chance, it seems to have hit
this issue due to the particular CGU partitioning and optimization
decisions that end up getting made.
2020-09-17 21:36:13 +00:00
|
|
|
SmallString<40> Key;
|
|
|
|
llvm::lto::Config conf;
|
2024-09-17 00:11:02 +00:00
|
|
|
const auto &ImportList = Data->ImportLists.lookup(ModId);
|
Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse
During incremental ThinLTO compilation, we attempt to re-use the
optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do
so.
Up until now, 'safe' has meant that the set of modules that our current
modules imports from/exports to is unchanged from the previous
compilation session. See PR #67020 and PR #71131 for more details.
However, this turns out be insufficient to guarantee that it's safe
to reuse the post-LTO module (i.e. that optimizing the pre-LTO module
would produce the same result). When LLVM optimizes a module during
ThinLTO, it may look at other information from the 'module index', such
as whether a (non-imported!) global variable is used. If this
information changes between compilation runs, we may end up re-using an
optimized module that (for example) had dead-code elimination run on a
function that is now used by another module.
Fortunately, LLVM implements its own ThinLTO module cache, which is used
when ThinLTO is performed by a linker plugin (e.g. when clang is used to
compile a C proect). Using this cache directly would require extensive
refactoring of our code - but fortunately for us, LLVM provides a
function that does exactly what we need.
The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash
from all data that might influence the result of ThinLTO on a module.
In addition to the module imports/exports that we manually track, it
also hashes information about global variables (e.g. their liveness)
which might be used during optimization. By using this function, we
shouldn't have to worry about new LLVM passes breaking our module re-use
behavior.
In LLVM, the output of this function forms part of the filename used to
store the post-ThinLTO module. To keep our current filename structure
intact, this PR just writes out the mapping 'CGU name -> Hash' to a
file. To determine if a post-LTO module should be reused, we compare
hashes from the previous session.
This should unblock PR #75199 - by sheer chance, it seems to have hit
this issue due to the particular CGU partitioning and optimization
decisions that end up getting made.
2020-09-17 21:36:13 +00:00
|
|
|
const auto &ExportList = Data->ExportLists.lookup(ModId);
|
|
|
|
const auto &ResolvedODR = Data->ResolvedODR.lookup(ModId);
|
|
|
|
const auto &DefinedGlobals = Data->ModuleToDefinedGVSummaries.lookup(ModId);
|
2024-08-21 09:58:11 +00:00
|
|
|
#if LLVM_VERSION_GE(20, 0)
|
|
|
|
DenseSet<GlobalValue::GUID> CfiFunctionDefs;
|
|
|
|
DenseSet<GlobalValue::GUID> CfiFunctionDecls;
|
|
|
|
#else
|
Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse
During incremental ThinLTO compilation, we attempt to re-use the
optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do
so.
Up until now, 'safe' has meant that the set of modules that our current
modules imports from/exports to is unchanged from the previous
compilation session. See PR #67020 and PR #71131 for more details.
However, this turns out be insufficient to guarantee that it's safe
to reuse the post-LTO module (i.e. that optimizing the pre-LTO module
would produce the same result). When LLVM optimizes a module during
ThinLTO, it may look at other information from the 'module index', such
as whether a (non-imported!) global variable is used. If this
information changes between compilation runs, we may end up re-using an
optimized module that (for example) had dead-code elimination run on a
function that is now used by another module.
Fortunately, LLVM implements its own ThinLTO module cache, which is used
when ThinLTO is performed by a linker plugin (e.g. when clang is used to
compile a C proect). Using this cache directly would require extensive
refactoring of our code - but fortunately for us, LLVM provides a
function that does exactly what we need.
The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash
from all data that might influence the result of ThinLTO on a module.
In addition to the module imports/exports that we manually track, it
also hashes information about global variables (e.g. their liveness)
which might be used during optimization. By using this function, we
shouldn't have to worry about new LLVM passes breaking our module re-use
behavior.
In LLVM, the output of this function forms part of the filename used to
store the post-ThinLTO module. To keep our current filename structure
intact, this PR just writes out the mapping 'CGU name -> Hash' to a
file. To determine if a post-LTO module should be reused, we compare
hashes from the previous session.
This should unblock PR #75199 - by sheer chance, it seems to have hit
this issue due to the particular CGU partitioning and optimization
decisions that end up getting made.
2020-09-17 21:36:13 +00:00
|
|
|
std::set<GlobalValue::GUID> CfiFunctionDefs;
|
|
|
|
std::set<GlobalValue::GUID> CfiFunctionDecls;
|
2024-08-21 09:58:11 +00:00
|
|
|
#endif
|
Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse
During incremental ThinLTO compilation, we attempt to re-use the
optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do
so.
Up until now, 'safe' has meant that the set of modules that our current
modules imports from/exports to is unchanged from the previous
compilation session. See PR #67020 and PR #71131 for more details.
However, this turns out be insufficient to guarantee that it's safe
to reuse the post-LTO module (i.e. that optimizing the pre-LTO module
would produce the same result). When LLVM optimizes a module during
ThinLTO, it may look at other information from the 'module index', such
as whether a (non-imported!) global variable is used. If this
information changes between compilation runs, we may end up re-using an
optimized module that (for example) had dead-code elimination run on a
function that is now used by another module.
Fortunately, LLVM implements its own ThinLTO module cache, which is used
when ThinLTO is performed by a linker plugin (e.g. when clang is used to
compile a C proect). Using this cache directly would require extensive
refactoring of our code - but fortunately for us, LLVM provides a
function that does exactly what we need.
The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash
from all data that might influence the result of ThinLTO on a module.
In addition to the module imports/exports that we manually track, it
also hashes information about global variables (e.g. their liveness)
which might be used during optimization. By using this function, we
shouldn't have to worry about new LLVM passes breaking our module re-use
behavior.
In LLVM, the output of this function forms part of the filename used to
store the post-ThinLTO module. To keep our current filename structure
intact, this PR just writes out the mapping 'CGU name -> Hash' to a
file. To determine if a post-LTO module should be reused, we compare
hashes from the previous session.
This should unblock PR #75199 - by sheer chance, it seems to have hit
this issue due to the particular CGU partitioning and optimization
decisions that end up getting made.
2020-09-17 21:36:13 +00:00
|
|
|
|
|
|
|
// Based on the 'InProcessThinBackend' constructor in LLVM
|
|
|
|
for (auto &Name : Data->Index.cfiFunctionDefs())
|
|
|
|
CfiFunctionDefs.insert(
|
|
|
|
GlobalValue::getGUID(GlobalValue::dropLLVMManglingEscape(Name)));
|
|
|
|
for (auto &Name : Data->Index.cfiFunctionDecls())
|
|
|
|
CfiFunctionDecls.insert(
|
|
|
|
GlobalValue::getGUID(GlobalValue::dropLLVMManglingEscape(Name)));
|
|
|
|
|
2024-08-21 09:58:11 +00:00
|
|
|
#if LLVM_VERSION_GE(20, 0)
|
|
|
|
Key = llvm::computeLTOCacheKey(conf, Data->Index, ModId, ImportList,
|
|
|
|
ExportList, ResolvedODR, DefinedGlobals,
|
|
|
|
CfiFunctionDefs, CfiFunctionDecls);
|
|
|
|
#else
|
2024-06-04 14:46:20 +00:00
|
|
|
llvm::computeLTOCacheKey(Key, conf, Data->Index, ModId, ImportList,
|
|
|
|
ExportList, ResolvedODR, DefinedGlobals,
|
|
|
|
CfiFunctionDefs, CfiFunctionDecls);
|
2024-08-21 09:58:11 +00:00
|
|
|
#endif
|
Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse
During incremental ThinLTO compilation, we attempt to re-use the
optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do
so.
Up until now, 'safe' has meant that the set of modules that our current
modules imports from/exports to is unchanged from the previous
compilation session. See PR #67020 and PR #71131 for more details.
However, this turns out be insufficient to guarantee that it's safe
to reuse the post-LTO module (i.e. that optimizing the pre-LTO module
would produce the same result). When LLVM optimizes a module during
ThinLTO, it may look at other information from the 'module index', such
as whether a (non-imported!) global variable is used. If this
information changes between compilation runs, we may end up re-using an
optimized module that (for example) had dead-code elimination run on a
function that is now used by another module.
Fortunately, LLVM implements its own ThinLTO module cache, which is used
when ThinLTO is performed by a linker plugin (e.g. when clang is used to
compile a C proect). Using this cache directly would require extensive
refactoring of our code - but fortunately for us, LLVM provides a
function that does exactly what we need.
The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash
from all data that might influence the result of ThinLTO on a module.
In addition to the module imports/exports that we manually track, it
also hashes information about global variables (e.g. their liveness)
which might be used during optimization. By using this function, we
shouldn't have to worry about new LLVM passes breaking our module re-use
behavior.
In LLVM, the output of this function forms part of the filename used to
store the post-ThinLTO module. To keep our current filename structure
intact, this PR just writes out the mapping 'CGU name -> Hash' to a
file. To determine if a post-LTO module should be reused, we compare
hashes from the previous session.
This should unblock PR #75199 - by sheer chance, it seems to have hit
this issue due to the particular CGU partitioning and optimization
decisions that end up getting made.
2020-09-17 21:36:13 +00:00
|
|
|
|
|
|
|
LLVMRustStringWriteImpl(KeyOut, Key.c_str(), Key.size());
|
|
|
|
}
|