| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds the following benchmarks:
- StringAssignStr
Assign a const basic::string& value
- StringAssignAsciiz
Assign a const char* asciiz value
StringAssignAsciizMix
Assign mixed long/short const char* asciiz values
- StringResizeDefaultInit
Resize default init benchmark
Patch by Martijn Vels (mvels@google.com)
Reviewed as D72343
|
| |
|
|
|
|
| |
Testing git commit access.
|
|
|
|
|
|
|
|
|
| |
It turns out that r374056 broke _some_ build bots again, specifically
the ones using sanitizers. Instead of trying to link the right system
libraries to the benchmarks bit-by-bit, let's just link exactly the
system libraries that libc++ itself needs.
llvm-svn: 374079
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the benchmarks build with -nostdlib, they need to manually link
against some system libraries that are used by the benchmarks and the
GoogleBenchmark library itself.
Previously, we'd rely on the fact that these libraries were linked
through the PUBLIC dependencies of cxx_shared/cxx_static. However,
if we were to make these dependencies PRIVATE (as they should be
because they are implementation details of libc++), the benchmarks
would fail to link. This commit remediates that.
llvm-svn: 374053
|
|
|
|
|
|
|
|
| |
It's better style to use PRIVATE when linking libraries to executables,
and it doesn't make a difference since executables don't need to propagate
their link-time dependencies anyway.
llvm-svn: 374050
|
|
|
|
|
|
|
|
|
|
|
| |
This allows propagating the include automatically to targets that
depend on one of the libc++ targets such as the benchmarks. Note
that the GoogleBenchmark build itself still needs to manually specify
the -include, since I don't know of any way to have an external project
link against one of the libc++ targets (which would propagate the -include
automatically).
llvm-svn: 373631
|
|
|
|
|
|
|
|
| |
LLVM uses .h as its extension for header files.
Differential Revision: https://reviews.llvm.org/D66509
llvm-svn: 369487
|
|
|
|
| |
llvm-svn: 369482
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM uses .h as its extension for header files.
Files renamed using:
for f in libcxx/test/support/*.hpp; do git mv $f ${f%.hpp}.h; done
References to the files updated using:
for f in $(git diff master | grep 'rename from' | cut -f 3 -d ' '); do
a=$(basename $f);
echo $a;
rg -l $a libcxx | xargs sed -i '' "s/$a/${a%.hpp}.h/";
done
HPP include guards updated manually using:
for f in $(git diff master | grep 'rename from' | cut -f 3 -d ' '); do
echo ${f%.hpp}.h ;
done | xargs mvim
Differential Revision: https://reviews.llvm.org/D66104
llvm-svn: 369481
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch rewrites a few loops in deque and split_buffer to better
optimize the codegen. For constructors like
`deque<unsigned char> d(500000, 0);` this patch results in a 2x speedup.
The patch improves the codegen in roughly three ways:
1. Changes do { ... } while (...) loops into more typical for loops.
The optimizer can reason about normal looking loops better.
2. Split the iteration over a range into (A) iteration over the blocks,
then (B) iteration within the block. This nested structure helps LLVM
lower the inner loop to `memset`.
3. Do fewer things each iteration. Some of these loops were incrementing
or changing 4-5 variables every loop (in addition to the
construction). Previously most loops would increment the end pointer,
the size, and decrement the count of remaining items to construct.
Now we only increment a single pointer for most iterations.
llvm-svn: 368547
|
|
|
|
| |
llvm-svn: 367722
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The optimizer is petulant and temperamental. In this case LLVM failed to lower
the the "insert at end" loop used by`vector<unsigned char>` to a `memset` despite
`memset` being substantially faster over a range of bytes.
LLVM has the ability to lower loops to `memset` whet appropriate, but the
odd nature of libc++'s loops prevented the optimization from taking places.
This patch addresses the issue by rewriting the loops from the form
`do [ ... --__n; } while (__n > 0);` to instead use a for loop over a pointer
range (For example: `for (auto *__i = ...; __i < __e; ++__i)`).
This patch also rewrites the asan annotations to unposion all additional memory
at the start of the loop instead of once per iterations. This could potentially
permit false negatives where the constructor of element N attempts to access
element N + 1 during its construction.
The before and after results for the `BM_ConstructSize/vector_byte/5140480_mean`
benchmark (run 5 times) are:
--------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------------------------------
Before
------
BM_ConstructSize/vector_byte/5140480_mean 12530140 ns 12469693 ns N/A
BM_ConstructSize/vector_byte/5140480_median 12512818 ns 12445571 ns N/A
BM_ConstructSize/vector_byte/5140480_stddev 106224 ns 107907 ns 5
-----
After
-----
BM_ConstructSize/vector_byte/5140480_mean 167285 ns 166500 ns N/A
BM_ConstructSize/vector_byte/5140480_median 166749 ns 166069 ns N/A
BM_ConstructSize/vector_byte/5140480_stddev 3242 ns 3184 ns 5
llvm-svn: 367183
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Instead of populating the global LIBCXX_LIBRARIES, we use the link-time
dependency management built into CMake to propagate link flags. This
leads to a cleaner and easier-to-follow build.
Reviewers: phosek, smeenai, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, mstorsjo, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60969
llvm-svn: 359571
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Comparing against the empty string should generate much better code that
what it does today.
We can also generate better code when comparing against literals that
are larger than the SSO space.
Reviewers: EricWF
Subscribers: christof, jdoerfert, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D59781
llvm-svn: 357614
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add relational benchmark against a string constant.
These can potentially trigger inlining of the operations. We want to
benchmark that.
Reviewers: EricWF
Subscribers: christof, jdoerfert, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D59512
llvm-svn: 356680
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch treats <filesystem> as a first-class citizen of the dylib,
like all other sub-libraries (e.g. <chrono>). As such, it also removes
all special handling for installing the filesystem library separately
or disabling part of the test suite from the lit command line.
Unlike the previous attempt (r356500), this doesn't remove all the
filesystem tests.
Reviewers: mclow.lists, EricWF, serge-sans-paille
Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59152
llvm-svn: 356518
|
|
|
|
|
|
|
|
| |
When I applied r356500 (https://reviews.llvm.org/D59152), I somehow
deleted all of filesystem's tests. I will revert r356500 and re-apply
it properly.
llvm-svn: 356505
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch treats <filesystem> as a first-class citizen of the dylib,
like all other sub-libraries (e.g. <chrono>). As such, it also removes
all special handling for installing the filesystem library separately
or disabling part of the test suite from the lit command line.
Reviewers: mclow.lists, EricWF, serge-sans-paille
Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59152
llvm-svn: 356500
|
|
|
|
|
|
|
|
|
|
|
| |
When linking library dependencies, we shouldn't need to export linked
libraries to dependents. We should be explicit about this in
target_link_libraries, otherwise other targets that depend on these such
as sanitizers get repeated (and possibly even conflicting) dependencies.
Differential Revision: https://reviews.llvm.org/D57456
llvm-svn: 352688
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
|
|
|
|
|
|
|
|
|
|
| |
This is a re-application of r345525, which had been reverted by fear of
a regression.
Reviewed as https://reviews.llvm.org/D53994.
Thanks to Denis Yaroshevskiy for the patch.
llvm-svn: 349358
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Benchmarks for std::sort, std::stable_sort, std::make_heap,
std::sort_heap, std::pop_heap and std::push_heap.
The benchmarks are run with integers and strings, and with different
sorted input.
Reviewers: EricWF
Subscribers: christof, mgrang, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53978
llvm-svn: 347329
|
|
|
|
| |
llvm-svn: 346989
|
|
|
|
| |
llvm-svn: 346933
|
|
|
|
| |
llvm-svn: 346905
|
|
|
|
| |
llvm-svn: 346904
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch renames the cxx-benchmark-unittests to check-cxx-benchmarks
and converts the target to use LIT in order to make the tests run faster
and provide better output.
In particular this runs each benchmark in a suite one by one, allowing
more parallelism while ensuring output isn't garbage with multiple threads.
Additionally, it adds the CMake flag '-DLIBCXX_BENCHMARK_TEST_ARGS=<list>'
to specify what options are passed when running the benchmarks.
llvm-svn: 346888
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds the cxx-benchmark-unittests target so we can start
getting test coverage on the benchmarks, including building with
sanitizers. Because we're only looking for test-coverage, the benchmarks
run for the shortest time possible, and in parallel.
The target is excluded from all by default. It only
builds and runs the libcxx configurations of the benchmarks, and not
any versions built against the systems native standard library.
llvm-svn: 346811
|
|
|
|
|
|
|
| |
An argument to DoNotOptimize was not fully initialized, which caused
msan to complain.
llvm-svn: 346808
|
|
|
|
|
|
|
|
|
|
|
| |
The usage of aligned_storage failed to pass the alignment it wanted,
which caused it to have a larger size and alignment that the
std::string's it was intended to store.
This patch manually specifies the alignment, as well as cleaning up
type alias bugs.
llvm-svn: 346779
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The benchmarks currently require C++17, however Clang 3.9 doesn't
support -std=c++17 while still supporting all the C++17 features needed
to compile the benchmarks.
This patch makes the benchmark build attempt to fall back to -std=c++1z
when -std=c++17 isn't supported.
See llvm.org/PR39629
llvm-svn: 346744
|
|
|
|
|
|
|
|
|
|
|
| |
using unsigned division by 2 when possible."
This reverts r345525. I'm reverting because that patch apparently caused
a regression on certain platforms (see https://reviews.llvm.org/D53994).
Since we don't fully understand the reasons for the regression, I'm
reverting until we can provide a fix we understand.
llvm-svn: 345893
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Added benchmarks for Construct, Copy, Move, Destroy, Relationals and
Read. On the ones that matter, the benchmarks tests hot and cold data,
and opaque and transparent inputs.
Reviewers: EricWF
Subscribers: christof, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53825
llvm-svn: 345611
|
|
|
|
|
|
|
|
|
|
|
|
| |
unsigned division by 2 when possible.
Patch by Denis Yaroshevskiy (denis.yaroshevskij@gmail.com)
The rational and measurements can be found in the bug description: https://bugs.llvm.org/show_bug.cgi?id=39129
Reviewed as https://reviews.llvm.org/D52697
llvm-svn: 345525
|
|
|
|
| |
llvm-svn: 345523
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Benchmarks for construct, find, insert and iterate, with sequential
and random ordered inputs.
It also improves the cartesian product benchmark header to allow for
runtime values to be specified in the product.
Reviewers: EricWF
Subscribers: christof, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53523
llvm-svn: 345035
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Benchmarks for construct, copy, move, swap, destroy and invoke, with 8
different input states.
For the cases that matter, it tests with and without allowing constant
value propagation from construction into the operation tested.
This also adds helper functions to generate the cartesian product of
different configurations and generate benchmarks for all of them.
Reviewers: EricWF
Subscribers: christof, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53087
llvm-svn: 344415
|
|
|
|
| |
llvm-svn: 344167
|
|
|
|
| |
llvm-svn: 344160
|
|
|
|
| |
llvm-svn: 336636
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a fairly large patch that implements all of the filesystem NB comments
and the relative paths changes (ex. adding weakly_canonical). These issues
and papers are all interrelated so their implementation couldn't be split up
nicely.
This patch upgrades <experimental/filesystem> to match the C++17 spec and not
the published experimental TS spec. Some of the changes in this patch are both
API and ABI breaking, however libc++ makes no guarantee about stability for
experimental implementations.
The major changes in this patch are:
* Implement NB comments for filesystem (P0492R2), including:
* Implement `perm_options` enum as part of NB comments, and update the
`permissions` function to match.
* Implement changes to `remove_filename` and `replace_filename`
* Implement changes to `path::stem()` and `path::extension()` which support
splitting examples like `.profile`.
* Change path iteration to return an empty path instead of '.' for trailing
separators.
* Change `operator/=` to handle absolute paths on the RHS.
* Change `absolute` to no longer accept a current path argument.
* Implement relative paths according to NB comments (P0219r1)
* Combine `path.cpp` and `operations.cpp` since some path functions require
access to the operations internals, and some fs operations require access
to the path parser.
llvm-svn: 329028
|
|
|
|
| |
llvm-svn: 322812
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
benchmarks/util_smartptr.bench.cpp
Change CRLF to LF.
test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
Consistently comment "\u20ac" as EURO SIGN, its Unicode name, instead of the actual Unicode character.
test/std/utilities/allocator.adaptor/allocator.adaptor.members/construct_type.pass.cpp
Avoid non-ASCII dash.
Fixes D40991.
llvm-svn: 320536
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function num_get<_CharT>::stage2_int_prep makes unnecessary copy of src
into atoms when char_type is char. This can be avoided by creating
a switch on type and just returning __src when char_type is char.
Added the test case to demonstrate performance improvement.
In order to avoid ABI incompatibilities, the changes are guarded
with a macro _LIBCPP_ABI_OPTIMIZED_LOCALE_NUM_GET
Differential Revision: https://reviews.llvm.org/D30268
Reviewed by: EricWF
llvm-svn: 305427
|
|
|
|
| |
llvm-svn: 300533
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
string::find used to call the generic algorithm ::find. The patch special
case string::find such that it ultimately gets converted to calls to memchr
and memcmp.
The patch improves the performance of the string::find routine by about 20x.
Without the patch, the performance on an x86_64-linux 3400 MHz machine is:
Benchmark Time CPU Iterations
-----------------------------------------------------------------
BM_StringFindNoMatch/10 4 ns 4 ns 166421326
BM_StringFindNoMatch/64 37 ns 37 ns 18754392
BM_StringFindNoMatch/512 268 ns 268 ns 2586060
BM_StringFindNoMatch/4k 2143 ns 2144 ns 328342
BM_StringFindNoMatch/32k 16910 ns 16917 ns 40623
BM_StringFindNoMatch/128k 67577 ns 67602 ns 10138
BM_StringFindAllMatch/1 3 ns 3 ns 265163471
BM_StringFindAllMatch/8 6 ns 6 ns 112582467
BM_StringFindAllMatch/64 36 ns 36 ns 19566457
BM_StringFindAllMatch/512 209 ns 209 ns 3318893
BM_StringFindAllMatch/4k 1618 ns 1618 ns 432963
BM_StringFindAllMatch/32k 12909 ns 12914 ns 54317
BM_StringFindAllMatch/128k 48342 ns 48361 ns 13922
BM_StringFindMatch1/1 33777 ns 33790 ns 20698
BM_StringFindMatch1/8 33940 ns 33953 ns 20619
BM_StringFindMatch1/64 34038 ns 34051 ns 20571
BM_StringFindMatch1/512 34217 ns 34230 ns 20480
BM_StringFindMatch1/4k 35510 ns 35524 ns 19752
BM_StringFindMatch1/32k 46438 ns 46456 ns 15030
BM_StringFindMatch2/1 33839 ns 33852 ns 20648
BM_StringFindMatch2/8 33950 ns 33963 ns 20594
BM_StringFindMatch2/64 33846 ns 33859 ns 20668
BM_StringFindMatch2/512 34023 ns 34036 ns 20279
BM_StringFindMatch2/4k 35422 ns 35436 ns 19716
BM_StringFindMatch2/32k 46570 ns 46588 ns 15027
With the patch applied
Benchmark Time CPU Iterations
-----------------------------------------------------------------
BM_StringFindNoMatch/10 5 ns 5 ns 133724346
BM_StringFindNoMatch/64 6 ns 6 ns 119312184
BM_StringFindNoMatch/512 13 ns 13 ns 51539628
BM_StringFindNoMatch/4k 77 ns 77 ns 8935934
BM_StringFindNoMatch/32k 551 ns 551 ns 1222808
BM_StringFindNoMatch/128k 2684 ns 2685 ns 259957
BM_StringFindAllMatch/1 7 ns 7 ns 98017959
BM_StringFindAllMatch/8 7 ns 7 ns 91466911
BM_StringFindAllMatch/64 8 ns 8 ns 85707392
BM_StringFindAllMatch/512 20 ns 20 ns 34490895
BM_StringFindAllMatch/4k 93 ns 93 ns 7360375
BM_StringFindAllMatch/32k 827 ns 828 ns 829944
BM_StringFindAllMatch/128k 3593 ns 3594 ns 195815
BM_StringFindMatch1/1 1332 ns 1332 ns 516354
BM_StringFindMatch1/8 1336 ns 1336 ns 495876
BM_StringFindMatch1/64 1338 ns 1339 ns 516656
BM_StringFindMatch1/512 1357 ns 1357 ns 510717
BM_StringFindMatch1/4k 1485 ns 1486 ns 461228
BM_StringFindMatch1/32k 2235 ns 2236 ns 318253
BM_StringFindMatch2/1 1335 ns 1335 ns 517105
BM_StringFindMatch2/8 1336 ns 1337 ns 518004
BM_StringFindMatch2/64 1344 ns 1345 ns 511751
BM_StringFindMatch2/512 1361 ns 1361 ns 508150
BM_StringFindMatch2/4k 1611 ns 1611 ns 463388
BM_StringFindMatch2/32k 2187 ns 2187 ns 317532
Patch written by Aditya Kumar and Sebastian Pop.
Differential Revision: https://reviews.llvm.org/D27068
llvm-svn: 290761
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
path uses string::append to construct, append, and concatenate paths. Unfortunatly
string::append has a strong exception safety guaranteed and if it can't prove
that the iterator operations don't throw then it will allocate a temporary
string copy to append to. However this extra allocation and copy is very
undesirable for path which doesn't have the same exception guarantees.
To work around this this patch adds string::__append_forward_unsafe which exposes
the std::string::append interface for forward iterators without enforcing
that the iterator is noexcept.
llvm-svn: 285532
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes a performance bug when constructing or appending to a path
from a string or c-string. Previously we called 'push_back' to append every
single character. This caused multiple re-allocation and copies when at most
one reallocation is necessary. The new behavior is to simply call
`string::append` so it can correctly handle reallocation.
For large strings this change is a ~4x improvement. This also makes our path
faster to construct than libstdc++'s.
llvm-svn: 285530
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch entirely rewrites the parsing logic for paths. Unlike the previous
implementation this one stores information about the current state; For example
if we are in a trailing separator or a root separator. This avoids the need for
extra lookahead (and extra work) when incrementing or decrementing an iterator.
Roughly this gives us a 15% speedup over the previous implementation.
Unfortunately this implementation is still a lot slower than libstdc++'s.
Because libstdc++ pre-parses and splits the path upon construction their
iterators are trivial to increment/decrement. This makes libc++ lazy parsing
100x slower than libstdc++. However the pre-parsing libstdc++ causes a ton
of extra and unneeded allocations when constructing the string. For example
`path("/foo/bar/")` would require at least 5 allocations with libstdc++
whereas libc++ uses only one. The non-allocating behavior is much preferable
when you consider filesystem usages like 'exists("/foo/bar/")'.
Even then libc++'s path seems to be twice as slow to simply construct compared
to libstdc++. More investigation is needed about this.
llvm-svn: 285526
|