84b0b52b03
In basic_string and vector, we've been encapsulating all exception throwing code paths in helper functions of a base class, which are defined in the compiled library. For example, __vector_base_common defines two methods, __throw_length_error() and __throw_out_of_range(), and the class is externally instantiated in the library. This was done a long time ago, but after investigating, I believe the goal of the current design was to: 1. Encapsulate the code to throw an exception (which is non-trivial) in an externally-defined function so that the important code paths that call it (e.g. vector::at) are free from that code. Basically, the intent is for the "hot" code path to contain a single conditional jump (based on checking the error condition) to an externally-defined function, which handles all the exception-throwing business. 2. Avoid defining this exception-throwing function once per instantiation of the class template. In other words, we want a single copy of __throw_length_error even if we have vector<int>, vector<char>, etc. 3. Encapsulate the passing of the container-specific string (i.e. "vector" and "basic_string") to the underlying exception-throwing function so that object files don't contain those duplicated string literals. For example, we'd like to have a single "vector" string literal for passing to `std::__throw_length_error` in the library, instead of having one per translation unit. However, the way this is achieved right now has two problems: - Using a base class and exporting it is really weird - I've been confused about this ever since I first saw it. It's just a really unusual way of achieving the above goals. Also, it's made even worse by the fact that the definitions of __throw_length_error and __throw_out_of_range appear in the headers despite always being intended to be defined in the compiled library (via the extern template instantiation). - We end up exporting those functions as weak symbols, which isn't great for load times. Instead, it would be better to export those as strong symbols from the library. This patch fixes those issues while retaining ABI compatibility (e.g. we still export the exact same symbols as before). Note that we need to keep the base classes as-is to avoid breaking the ABI of someone who might inherit from std::basic_string or std::vector. Differential Revision: https://reviews.llvm.org/D111173 |
||
---|---|---|
.github | ||
clang | ||
clang-tools-extra | ||
compiler-rt | ||
cross-project-tests | ||
flang | ||
libc | ||
libclc | ||
libcxx | ||
libcxxabi | ||
libunwind | ||
lld | ||
lldb | ||
llvm | ||
mlir | ||
openmp | ||
parallel-libs | ||
polly | ||
pstl | ||
runtimes | ||
utils | ||
.arcconfig | ||
.arclint | ||
.clang-format | ||
.clang-tidy | ||
.git-blame-ignore-revs | ||
.gitignore | ||
.mailmap | ||
CONTRIBUTING.md | ||
README.md | ||
SECURITY.md |
README.md
The LLVM Compiler Infrastructure
This directory and its sub-directories contain source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.
The README briefly describes how to get started with building LLVM. For more information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.
Getting Started with the LLVM System
Taken from https://llvm.org/docs/GettingStarted.html.
Overview
Welcome to the LLVM project!
The LLVM project has multiple components. The core of the project is itself called "LLVM". This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer. It also contains basic regression tests.
C-like languages use the Clang front end. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
Other components include: the libc++ C++ standard library, the LLD linker, and more.
Getting the Source Code and Building LLVM
The LLVM Getting Started documentation may be out of date. The Clang Getting Started page might have more accurate information.
This is an example work-flow and configuration to get and build the LLVM source:
-
Checkout LLVM (including related sub-projects like Clang):
-
git clone https://github.com/llvm/llvm-project.git
-
Or, on windows,
git clone --config core.autocrlf=false https://github.com/llvm/llvm-project.git
-
-
Configure and build LLVM and Clang:
-
cd llvm-project
-
cmake -S llvm -B build -G <generator> [options]
Some common build system generators are:
Ninja
--- for generating Ninja build files. Most llvm developers use Ninja.Unix Makefiles
--- for generating make-compatible parallel makefiles.Visual Studio
--- for generating Visual Studio projects and solutions.Xcode
--- for generating Xcode projects.
Some Common options:
-
-DLLVM_ENABLE_PROJECTS='...'
--- semicolon-separated list of the LLVM sub-projects you'd like to additionally build. Can include any of: clang, clang-tools-extra, compiler-rt,cross-project-tests, flang, libc, libclc, libcxx, libcxxabi, libunwind, lld, lldb, mlir, openmp, parallel-libs, polly, or pstl.For example, to build LLVM, Clang, libcxx, and libcxxabi, use
-DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi"
. -
-DCMAKE_INSTALL_PREFIX=directory
--- Specify for directory the full path name of where you want the LLVM tools and libraries to be installed (default/usr/local
). -
-DCMAKE_BUILD_TYPE=type
--- Valid options for type are Debug, Release, RelWithDebInfo, and MinSizeRel. Default is Debug. -
-DLLVM_ENABLE_ASSERTIONS=On
--- Compile with assertion checks enabled (default is Yes for Debug builds, No for all other build types).
-
cmake --build build [-- [options] <target>]
or your build system specified above directly.-
The default target (i.e.
ninja
ormake
) will build all of LLVM. -
The
check-all
target (i.e.ninja check-all
) will run the regression tests to ensure everything is in working order. -
CMake will generate targets for each tool and library, and most LLVM sub-projects generate their own
check-<project>
target. -
Running a serial build will be slow. To improve speed, try running a parallel build. That's done by default in Ninja; for
make
, use the option-j NNN
, whereNNN
is the number of parallel jobs, e.g. the number of CPUs you have.
-
-
For more information see CMake
-
Consult the Getting Started with LLVM page for detailed information on configuring and compiling LLVM. You can visit Directory Layout to learn about the layout of the source code tree.