[all-commits] [llvm/llvm-project] 84b0b5: [libc++] Refactor how basic_string and vector hois...
Louis Dionne via All-commits
all-commits at lists.llvm.org
Tue Oct 5 17:54:00 PDT 2021
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: 84b0b52b036cc1fbe2b88038fd700e83b7b67055
https://github.com/llvm/llvm-project/commit/84b0b52b036cc1fbe2b88038fd700e83b7b67055
Author: Louis Dionne <ldionne.2 at gmail.com>
Date: 2021-10-05 (Tue, 05 Oct 2021)
Changed paths:
M libcxx/include/string
M libcxx/include/vector
M libcxx/src/string.cpp
M libcxx/src/vector.cpp
Log Message:
-----------
[libc++] Refactor how basic_string and vector hoist exception-throwing functions
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
More information about the All-commits
mailing list