The Clang binary (and any binary linking Clang as a library), when built
using PIE, ends up with a pretty shocking number of dynamic relocations
to apply to the executable image: roughly 400k.
Each of these takes up binary space in the executable, and perhaps most
interestingly takes start-up time to apply the relocations.
The largest pattern I identified were the strings used to describe
target builtins. The addresses of these string literals were stored into
huge arrays, each one requiring a dynamic relocation. The way to avoid
this is to design the target builtins to use a single large table of
strings and offsets within the table for the individual strings. This
switches the builtin management to such a scheme.
This saves over 100k dynamic relocations by my measurement, an over 25%
reduction. Just looking at byte size improvements, using the `bloaty`
tool to compare a newly built `clang` binary to an old one:
```
FILE SIZE VM SIZE
-------------- --------------
+1.4% +653Ki +1.4% +653Ki .rodata
+0.0% +960 +0.0% +960 .text
+0.0% +197 +0.0% +197 .dynstr
+0.0% +184 +0.0% +184 .eh_frame
+0.0% +96 +0.0% +96 .dynsym
+0.0% +40 +0.0% +40 .eh_frame_hdr
+114% +32 [ = ] 0 [Unmapped]
+0.0% +20 +0.0% +20 .gnu.hash
+0.0% +8 +0.0% +8 .gnu.version
+0.9% +7 +0.9% +7 [LOAD #2 [R]]
[ = ] 0 -75.4% -3.00Ki .relro_padding
-16.1% -802Ki -16.1% -802Ki .data.rel.ro
-27.3% -2.52Mi -27.3% -2.52Mi .rela.dyn
-1.6% -2.66Mi -1.6% -2.66Mi TOTAL
```
We get a 16% reduction in the `.data.rel.ro` section, and nearly 30%
reduction in `.rela.dyn` where those reloctaions are stored.
This is also visible in my benchmarking of binary start-up overhead at
least:
```
Benchmark 1: ./old_clang --version
Time (mean ± σ): 17.6 ms ± 1.5 ms [User: 4.1 ms, System: 13.3 ms]
Range (min … max): 14.2 ms … 22.8 ms 162 runs
Benchmark 2: ./new_clang --version
Time (mean ± σ): 15.5 ms ± 1.4 ms [User: 3.6 ms, System: 11.8 ms]
Range (min … max): 12.4 ms … 20.3 ms 216 runs
Summary
'./new_clang --version' ran
1.13 ± 0.14 times faster than './old_clang --version'
```
We get about 2ms faster `--version` runs. While there is a lot of noise
in binary execution time, this delta is pretty consistent, and
represents over 10% improvement. This is particularly interesting to me
because for very short source files, repeatedly starting the `clang`
binary is actually the dominant cost. For example, `configure` scripts
running against the `clang` compiler are slow in large part because of
binary start up time, not the time to process the actual inputs to the
compiler.
----
This PR implements the string tables using `constexpr` code and the
existing macro system. I understand that the builtins are moving towards
a TableGen model, and if complete that would provide more options for
modeling this. Unfortunately, that migration isn't complete, and even
the parts that are migrated still rely on the ability to break out of
the TableGen model and directly expand an X-macro style `BUILTIN(...)`
textually. I looked at trying to complete the move to TableGen, but it
would both require the difficult migration of the remaining targets, and
solving some tricky problems with how to move away from any macro-based
expansion.
I was also able to find a reasonably clean and effective way of doing
this with the existing macros and some `constexpr` code that I think is
clean enough to be a pretty good intermediate state, and maybe give a
good target for the eventual TableGen solution. I was also able to
factor the macros into set of consistent patterns that avoids a
significant regression in overall boilerplate.
133 lines
5.0 KiB
C++
133 lines
5.0 KiB
C++
//===--- SPIR.cpp - Implement SPIR and SPIR-V target feature support ------===//
|
|
//
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
//
|
|
//===----------------------------------------------------------------------===//
|
|
//
|
|
// This file implements SPIR and SPIR-V TargetInfo objects.
|
|
//
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#include "SPIR.h"
|
|
#include "AMDGPU.h"
|
|
#include "Targets.h"
|
|
#include "llvm/TargetParser/TargetParser.h"
|
|
|
|
using namespace clang;
|
|
using namespace clang::targets;
|
|
|
|
void SPIRTargetInfo::getTargetDefines(const LangOptions &Opts,
|
|
MacroBuilder &Builder) const {
|
|
DefineStd(Builder, "SPIR", Opts);
|
|
}
|
|
|
|
void SPIR32TargetInfo::getTargetDefines(const LangOptions &Opts,
|
|
MacroBuilder &Builder) const {
|
|
SPIRTargetInfo::getTargetDefines(Opts, Builder);
|
|
DefineStd(Builder, "SPIR32", Opts);
|
|
}
|
|
|
|
void SPIR64TargetInfo::getTargetDefines(const LangOptions &Opts,
|
|
MacroBuilder &Builder) const {
|
|
SPIRTargetInfo::getTargetDefines(Opts, Builder);
|
|
DefineStd(Builder, "SPIR64", Opts);
|
|
}
|
|
|
|
void BaseSPIRVTargetInfo::getTargetDefines(const LangOptions &Opts,
|
|
MacroBuilder &Builder) const {
|
|
DefineStd(Builder, "SPIRV", Opts);
|
|
}
|
|
|
|
void SPIRVTargetInfo::getTargetDefines(const LangOptions &Opts,
|
|
MacroBuilder &Builder) const {
|
|
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
|
|
}
|
|
|
|
void SPIRV32TargetInfo::getTargetDefines(const LangOptions &Opts,
|
|
MacroBuilder &Builder) const {
|
|
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
|
|
DefineStd(Builder, "SPIRV32", Opts);
|
|
}
|
|
|
|
void SPIRV64TargetInfo::getTargetDefines(const LangOptions &Opts,
|
|
MacroBuilder &Builder) const {
|
|
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
|
|
DefineStd(Builder, "SPIRV64", Opts);
|
|
}
|
|
|
|
static const AMDGPUTargetInfo AMDGPUTI(llvm::Triple("amdgcn-amd-amdhsa"), {});
|
|
|
|
ArrayRef<const char *> SPIRV64AMDGCNTargetInfo::getGCCRegNames() const {
|
|
return AMDGPUTI.getGCCRegNames();
|
|
}
|
|
|
|
bool SPIRV64AMDGCNTargetInfo::initFeatureMap(
|
|
llvm::StringMap<bool> &Features, DiagnosticsEngine &Diags, StringRef,
|
|
const std::vector<std::string> &FeatureVec) const {
|
|
llvm::AMDGPU::fillAMDGPUFeatureMap({}, getTriple(), Features);
|
|
|
|
return TargetInfo::initFeatureMap(Features, Diags, {}, FeatureVec);
|
|
}
|
|
|
|
bool SPIRV64AMDGCNTargetInfo::validateAsmConstraint(
|
|
const char *&Name, TargetInfo::ConstraintInfo &Info) const {
|
|
return AMDGPUTI.validateAsmConstraint(Name, Info);
|
|
}
|
|
|
|
std::string
|
|
SPIRV64AMDGCNTargetInfo::convertConstraint(const char *&Constraint) const {
|
|
return AMDGPUTI.convertConstraint(Constraint);
|
|
}
|
|
|
|
std::pair<const char *, ArrayRef<Builtin::Info>>
|
|
SPIRV64AMDGCNTargetInfo::getTargetBuiltinStorage() const {
|
|
return AMDGPUTI.getTargetBuiltinStorage();
|
|
}
|
|
|
|
void SPIRV64AMDGCNTargetInfo::getTargetDefines(const LangOptions &Opts,
|
|
MacroBuilder &Builder) const {
|
|
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
|
|
DefineStd(Builder, "SPIRV64", Opts);
|
|
|
|
Builder.defineMacro("__AMD__");
|
|
Builder.defineMacro("__AMDGPU__");
|
|
Builder.defineMacro("__AMDGCN__");
|
|
}
|
|
|
|
void SPIRV64AMDGCNTargetInfo::setAuxTarget(const TargetInfo *Aux) {
|
|
assert(Aux && "Cannot invoke setAuxTarget without a valid auxiliary target!");
|
|
|
|
// This is a 1:1 copy of AMDGPUTargetInfo::setAuxTarget()
|
|
assert(HalfFormat == Aux->HalfFormat);
|
|
assert(FloatFormat == Aux->FloatFormat);
|
|
assert(DoubleFormat == Aux->DoubleFormat);
|
|
|
|
// On x86_64 long double is 80-bit extended precision format, which is
|
|
// not supported by AMDGPU. 128-bit floating point format is also not
|
|
// supported by AMDGPU. Therefore keep its own format for these two types.
|
|
auto SaveLongDoubleFormat = LongDoubleFormat;
|
|
auto SaveFloat128Format = Float128Format;
|
|
auto SaveLongDoubleWidth = LongDoubleWidth;
|
|
auto SaveLongDoubleAlign = LongDoubleAlign;
|
|
copyAuxTarget(Aux);
|
|
LongDoubleFormat = SaveLongDoubleFormat;
|
|
Float128Format = SaveFloat128Format;
|
|
LongDoubleWidth = SaveLongDoubleWidth;
|
|
LongDoubleAlign = SaveLongDoubleAlign;
|
|
// For certain builtin types support on the host target, claim they are
|
|
// supported to pass the compilation of the host code during the device-side
|
|
// compilation.
|
|
// FIXME: As the side effect, we also accept `__float128` uses in the device
|
|
// code. To reject these builtin types supported in the host target but not in
|
|
// the device target, one approach would support `device_builtin` attribute
|
|
// so that we could tell the device builtin types from the host ones. This
|
|
// also solves the different representations of the same builtin type, such
|
|
// as `size_t` in the MSVC environment.
|
|
if (Aux->hasFloat128Type()) {
|
|
HasFloat128 = true;
|
|
Float128Format = DoubleFormat;
|
|
}
|
|
}
|