Summary:
In certain cases vector can use memcpy to construct a range of elements at the back of the vector. We currently don't do this resulting in terrible code gen in non-optimized mode and a
very large slowdown compared to libstdc++.
This patch adds a `__construct_forward_range(Allocator, Iter, Iter, _Ptr&)` and `__construct_forward_range(Allocator, Tp*, Tp*, Tp*&)` functions to `allocator_traits` which act similarly to the existing `__construct_forward(...)` functions.
This patch also changes vectors `__construct_at_end(Iter, Iter)` to be `__construct_at_end(Iter, Iter, SizeType)` where SizeType is the size of the range. `__construct_at_end(Iter, Iter, SizeType)` now calls `allocator_traits<Tp>::__construct_forward_range(...)`.
This patch is based off the design of `__swap_out_circular_buffer(...)` which uses `allocator_traits<Tp>::__construct_forward(...)`.
On my machine this code performs 4x better than the current implementation when tested against `std::vector<int>`.
Reviewers: howard.hinnant, titus, kcc, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8109
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@233711 91177308-0d34-0410-b5e6-96231b3b80d8
Visual Studio's SAL extension uses a macro named __deallocate. This macro is
used pervasively, and gets included through various different ways. This
conflicts with the similarly named interfaces in libc++. Introduce a undef
header similar to __undef_min_max to handle this. This fixes a number of errors
due to the macro replacing the function name.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@229162 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch add support for "fancy pointers/allocators" as well as fixing support for shared_pointer and "minimal" allocators.
Fancy pointers are class types that meet the NullablePointer requirements. In our case they are created by fancy allocators. `support/min_allocator.h` is an archetype for these types.
There are three types of changes made in this patch:
1. `_Alloc::template rebind<T>::other` -> `__allocator_traits_rebind<_Alloc, T>::type`. This change was made because allocators don't need a rebind template. `__allocator_traits_rebind` is used instead of `allocator_traits::rebind` because use of `allocator_traits::rebind` requires a workaround for when template aliases are unavailable.
2. `a.deallocate(this, 1)` -> `a.deallocate(pointer_traits<self>::pointer_to(*this), 1)`. This change change is made because fancy pointers aren't always constructible from raw pointers.
3. `p.get()` -> `addressof(*p.get())`. Fancy pointers aren't actually a pointer. When we need a "real" pointer we take the address of dereferencing the fancy pointer. This should give us the actual raw pointer.
Test Plan: Tests were added using `support/min_allocator.h` to each affected shared_ptr overload and creation function. These tests can only be executed in C++11 or greater since min_allocator is only available then. A extra test was added for the non-variadic versions of allocate_shared.
Reviewers: danalbert, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4859
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@220469 91177308-0d34-0410-b5e6-96231b3b80d8
GCC will treat the default function template arguments as a
compilation error if C++0x is not enabled.
This commit workaround the compilation error by moving the
SFINAE check to function argument instead of the template
argument.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@200523 91177308-0d34-0410-b5e6-96231b3b80d8
pair, and a couple of pair-like implementation detail types. The
C++98/03 and 11 standards all specify that the copy constructor of
pair<int, int> is trivial. However as libc++ tracked the draft C++11
standard over the years, this copy constructor became non-trivial, and
then just recently was corrected back to trivial for C++11.
Unfortunately (for libc++1) the Itanium ABI specifies different calling
conventions for trivial and non-trivial copy constructors. Therefore
currently the C++03 libc++ copy constructor for pair<int, int> is ABI
incompatible with the C++11 libc++ copy constructor for pair<int, int>.
This is Bad(tm). This patch corrects the situation by making this copy
constructor trivial in C++03 mode as well.
Just in case it is needed for an incomplete C++11 compiler, libc++
retains the ability to support pair with rvalue references, but without
defaulted special members. However the pair needs non-trivial special
members to implement this special case, (as it did when clang was in
this place a couple of years ago).
During this work a bug was also found and fixed in
is_trivially_constructible.
And there is a minor drive-by fix in <__config> regarding
__type_visibility__.
A test is updated to ensure that the copy constructor of pair<int, int>
is trivial in both C++03 and C++11. This test will necessarily fail for
a compiler that implements rvalue references but not defaulted special
members.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@194536 91177308-0d34-0410-b5e6-96231b3b80d8
x86/x86-64 clang optimizes to direct word accesses anyway. This fixes an unaligned word access in murmurhash/cityhash.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@185558 91177308-0d34-0410-b5e6-96231b3b80d8
section in libc++. This requires a recompiled dylib. Failure to rebuild
the dylib will result in a link-time error if and only if the functions from
[util.smartptr.shared.atomic] are used.
The implementation is not lock free. After considerable thought, I know of no
way to make the implementation lock free. Ideas welcome along that front. But
changing the ABI of shared_ptr is not on the table at this point.
The mutex used to lock these function is encapsulated by std::__sp_mut. The
only thing the client knows about std::__sp_mut is that it has a void* data
member, can't be constructed, and has lock and unlock members. Within the
binary __sp_mut is currently implemented as a pointer to a std::mutex. That can
change in the future without disturbing the ABI (as long as sizeof(__sp_mut)
remains constant.
I specifically did not make __sp_mut a spin lock as I have a pathological
distrust of spin locks. Testing on OS X reveals that the use of std::mutex in
this role is not a large performance penalty as long as the contention for the
mutex is low (more likely to get the lock than to have to wait). In the future
we can still make __sp_mut a spin lock if that is what is desired (without ABI
damage).
The dylib contains 16 __sp_mut's to be chosen based on the hash of the address
of the shared_ptr. The constant 16 is a ball-park reasonable space/time
tradeoff.
std::hash<T*> was changed to call __murmur2_or_cityhash, instead of the identity
function. I had thought we had already done this, but I was mistaken.
All of this is under #if __has_feature(cxx_atomic) even though the
implementation is not lock free, because the signatures require access to
std::memory_order, which is currently available only under
__has_feature(cxx_atomic).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@160940 91177308-0d34-0410-b5e6-96231b3b80d8
