maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
415,099 Commits 23 Branches 0 Tags 2.2 GiB
Commit Graph

13 Commits

Author SHA1 Message Date
Arthur O'Dwyer fa6b9e4010 [libc++] Normalize all our '#pragma GCC system_header', and regression-test. 
Now we'll notice if a header forgets to include this magic phrase.

Differential Revision: https://reviews.llvm.org/D118800
 2022-02-04 12:27:19 -05:00
Arthur O'Dwyer 4d81a46f7f [libc++] Alphabetize header #includes. NFCI. 
The NFC part of D116809. We still want to enforce this in CI,
but the mechanism for that is still to-be-determined.

Differential Revision: https://reviews.llvm.org/D116809
 2022-01-10 16:30:38 -05:00
Fabian Wolff dc1c27149f [libc++] Cast to the right `difference_type` in various algorithms 
Differential Revision: https://reviews.llvm.org/D113868
 2021-11-18 17:07:36 -05:00
Arthur O'Dwyer 1ce516d43f [libc++] Minor fixups in the new introsort code. 
Differential Revision: https://reviews.llvm.org/D114133
 2021-11-18 11:01:41 -05:00
Danila Kutenin a45d2287ad [libc++] Unspecified behavior randomization in libc++ 
This effort is dedicated to deflake the tests of the users which depend
on the unspecified behavior of algorithms and containers. This also
might help updating the sorting algorithm in libcxx which has the
quadratic worst case in the future or at least create a new one under
flag.

For detailed design, please see the design doc I provide in the patch.

Differential Revision: https://reviews.llvm.org/D96946
 2021-11-16 15:55:33 -05:00
Nilay Vaish 7f287390d7 [libc++] Add introsort to avoid O(n^2) behavior 
This commit adds a benchmark that tests std::sort on an adversarial inputs,
and uses introsort in std::sort to avoid O(n^2) behavior on adversarial
inputs.

Inputs where partitions are unbalanced even after 2 log(n) pivots have
been selected, the algorithm switches to heap sort to avoid the
possibility of spending O(n^2) time on sorting the input.
Benchmark results show that the intro sort implementation does
significantly better.

Benchmarking results before this change. Time represents the sorting
time required per element:

----------------------------------------------------------------------------------------------------------
Benchmark                                                                Time             CPU   Iterations
----------------------------------------------------------------------------------------------------------
BM_Sort_uint32_QuickSortAdversary_1                                   3.75 ns         3.74 ns    187432960
BM_Sort_uint32_QuickSortAdversary_4                                   3.05 ns         3.05 ns    231211008
BM_Sort_uint32_QuickSortAdversary_16                                  2.45 ns         2.45 ns    288096256
BM_Sort_uint32_QuickSortAdversary_64                                  32.8 ns         32.8 ns     21495808
BM_Sort_uint32_QuickSortAdversary_256                                  132 ns          132 ns      5505024
BM_Sort_uint32_QuickSortAdversary_1024                                 498 ns          497 ns      1572864
BM_Sort_uint32_QuickSortAdversary_16384                               3846 ns         3845 ns       262144
BM_Sort_uint32_QuickSortAdversary_262144                             61431 ns        61400 ns       262144
BM_Sort_uint64_QuickSortAdversary_1                                   3.93 ns         3.92 ns    181141504
BM_Sort_uint64_QuickSortAdversary_4                                   3.10 ns         3.09 ns    222560256
BM_Sort_uint64_QuickSortAdversary_16                                  2.50 ns         2.50 ns    283639808
BM_Sort_uint64_QuickSortAdversary_64                                  33.2 ns         33.2 ns     21757952
BM_Sort_uint64_QuickSortAdversary_256                                  132 ns          132 ns      5505024
BM_Sort_uint64_QuickSortAdversary_1024                                 478 ns          477 ns      1572864
BM_Sort_uint64_QuickSortAdversary_16384                               3932 ns         3930 ns       262144
BM_Sort_uint64_QuickSortAdversary_262144                             61646 ns        61615 ns       262144

Benchmarking results after this change:

----------------------------------------------------------------------------------------------------------
Benchmark                                                                Time             CPU   Iterations
----------------------------------------------------------------------------------------------------------
BM_Sort_uint32_QuickSortAdversary_1                                   6.31 ns         6.30 ns    107741184
BM_Sort_uint32_QuickSortAdversary_4                                   4.51 ns         4.50 ns    158859264
BM_Sort_uint32_QuickSortAdversary_16                                  3.00 ns         3.00 ns    223608832
BM_Sort_uint32_QuickSortAdversary_64                                  44.8 ns         44.8 ns     15990784
BM_Sort_uint32_QuickSortAdversary_256                                 69.0 ns         68.9 ns      9961472
BM_Sort_uint32_QuickSortAdversary_1024                                 118 ns          118 ns      6029312
BM_Sort_uint32_QuickSortAdversary_16384                                175 ns          175 ns      4194304
BM_Sort_uint32_QuickSortAdversary_262144                               210 ns          210 ns      3407872
BM_Sort_uint64_QuickSortAdversary_1                                   6.75 ns         6.73 ns    103809024
BM_Sort_uint64_QuickSortAdversary_4                                   4.53 ns         4.53 ns    160432128
BM_Sort_uint64_QuickSortAdversary_16                                  2.98 ns         2.97 ns    234356736
BM_Sort_uint64_QuickSortAdversary_64                                  44.3 ns         44.3 ns     15990784
BM_Sort_uint64_QuickSortAdversary_256                                 69.2 ns         69.2 ns     10223616
BM_Sort_uint64_QuickSortAdversary_1024                                 119 ns          119 ns      6029312
BM_Sort_uint64_QuickSortAdversary_16384                                173 ns          173 ns      4194304
BM_Sort_uint64_QuickSortAdversary_262144                               212 ns          212 ns      3407872

Differential Revision: https://reviews.llvm.org/D113413
 2021-11-16 11:38:46 -05:00
Louis Dionne f4c1258d56 [libc++] Add an option to disable wide character support in libc++ 
Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It makes sense for
libc++ to work properly on those platforms, so this commit adds a carve-out
of functionality for wchar_t.

Unfortunately, unlike some other carve-outs (e.g. random device), this
patch touches several parts of the library. However, despite the wide
impact of this patch, I still think it is important to support this
configuration since it makes it much simpler to port libc++ to some
embedded platforms.

Differential Revision: https://reviews.llvm.org/D111265
 2021-10-12 06:08:23 -04:00
Louis Dionne 64184b4af0 [libc++][NFC] Remove useless _LIBCPP_PUSH_MACROS 
Only files that actually use min/max are required to do this dance.

Differential Revision: https://reviews.llvm.org/D108778
 2021-08-27 12:41:55 -04:00
Arthur O'Dwyer ca7926bd79 [libc++] Eliminate needless `add_lvalue_reference` from <algorithm> helpers. NFCI. 
When `_Compare` is a function parameter already (so it's not `void`
and it's not an abominable function type), `add_lvalue_reference_t<_Compare>`
is simply a synonym for `_Compare&`. We don't need to pull in `<type_traits>`
and instantiate a template trait to figure that out.

Differential Revision: https://reviews.llvm.org/D108400
 2021-08-22 11:43:12 -04:00
Christopher Di Bella 6adbc83ee9 [libcxx][modularisation] moves <utility> content out of <type_traits> 
Moves:

* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
  `__utility/${FUNCTION_NAME}`.
* `std::swap_ranges` and `std::iter_swap` into
  `__algorithm/${FUNCTION_NAME}`

Differential Revision: https://reviews.llvm.org/D103734
 2021-06-24 17:57:29 +00:00
Louis Dionne 134723edd5 [libcxx] Move all algorithms into their own headers 
This is a fairly mechanical change, it just moves each algorithm into
its own header. This is intended to be a NFC.

This commit re-applies 7ed7d4ccb8, which was reverted in 692d7166f7
because the Modules build got broken. The modules build has now been
fixed, so we're re-committing this.

Differential Revision: https://reviews.llvm.org/D103583

Attribution note
----------------
I'm only committing this. This commit is a mix of D103583, D103330 and
D104171 authored by:

Co-authored-by: Christopher Di Bella <cjdb@google.com>
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
 2021-06-19 07:49:06 -04:00
Petr Hosek 692d7166f7 Revert "[libcxx][gardening] Move all algorithms into their own headers." 
This reverts commit 7ed7d4ccb8 as it
uncovered a Clang bug PR50592.
 2021-06-07 17:15:20 -07:00
zoecarver 7ed7d4ccb8 [libcxx][gardening] Move all algorithms into their own headers. 
This is a fairly mechanical change, it just moves each algorithm into its own header. This is a NFC.

Note: during this change, I burned down all the includes, so this follows "include only and exactly what you use."

Differential Revision: https://reviews.llvm.org/D103583
 2021-06-04 09:37:12 -07:00