shylie/llvm-project
1
0
Fork 0
Code Issues Pull Requests Actions 6 Packages Projects Releases Wiki Activity
568,685 Commits 1,713 Branches 298 Tags
Commit Graph

17 Commits

Author SHA1 Message Date
Nikolas Klauser
fc5e0c071b
[libc++] Simplify most of the segmented iterator optimizations (#164797) 
This patch does two things.
(1) It replaces SFINAE with `if constexpr`, avoiding some overload
resolution and unnecessary boilerplate.
(2) It removes an overload from `__for_each_n` to forward to
`__for_each`, since `__for_each` doesn't provide any further
optimizations.
 2025-11-07 08:27:55 +01:00
Peng Liu
d0cee6939a
[libc++] Optimize std::{,ranges}::{fill,fill_n} for segmented iterators (#132665) 
This patch optimizes `std::fill`, `std::fill_n`, `std::ranges::fill`,
and `std::ranges::fill_n` for segmented iterators, achieving substantial
performance improvements. Specifically, for `deque<int>` iterators, the
performance improvements are above 10x for all these algorithms. The
optimization also enables filling segmented memory of `deque<int>` to
approach the performance of filling contiguous memory of `vector<int>`.


Benchmark results comparing the before and after implementations are
provided below. For additional context, we’ve included `vector<int>`
results, which remain unchanged, as this patch specifically targets
segmented iterators and leaves non-segmented iterator behavior
untouched.



Fixes two subtasks outlined in #102817.

#### `fill_n`

```
-----------------------------------------------------------------------------
Benchmark                                Before            After      Speedup
-----------------------------------------------------------------------------
std::fill_n(deque<int>)/32              11.4 ns          2.28 ns        5.0x
std::fill_n(deque<int>)/50              19.7 ns          3.40 ns        5.8x
std::fill_n(deque<int>)/1024             391 ns          37.3 ns       10.5x
std::fill_n(deque<int>)/8192            3174 ns           301 ns       10.5x
std::fill_n(deque<int>)/65536          26504 ns          2951 ns        9.0x
std::fill_n(deque<int>)/1048576       407960 ns         80658 ns        5.1x
rng::fill_n(deque<int>)/32              14.3 ns          2.15 ns        6.6x
rng::fill_n(deque<int>)/50              20.2 ns          3.22 ns        6.3x
rng::fill_n(deque<int>)/1024             381 ns          37.8 ns       10.1x
rng::fill_n(deque<int>)/8192            3101 ns           294 ns       10.5x
rng::fill_n(deque<int>)/65536          25098 ns          2926 ns        8.6x
rng::fill_n(deque<int>)/1048576       394342 ns         78874 ns        5.0x
std::fill_n(vector<int>)/32             1.76 ns          1.72 ns        1.0x
std::fill_n(vector<int>)/50             3.00 ns          2.73 ns        1.1x
std::fill_n(vector<int>)/1024           38.4 ns          37.9 ns        1.0x
std::fill_n(vector<int>)/8192            258 ns           252 ns        1.0x
std::fill_n(vector<int>)/65536          2993 ns          2889 ns        1.0x
std::fill_n(vector<int>)/1048576       80328 ns         80468 ns        1.0x
rng::fill_n(vector<int>)/32             1.99 ns          1.35 ns        1.5x
rng::fill_n(vector<int>)/50             2.66 ns          2.12 ns        1.3x
rng::fill_n(vector<int>)/1024           37.7 ns          35.8 ns        1.1x
rng::fill_n(vector<int>)/8192            253 ns           250 ns        1.0x
rng::fill_n(vector<int>)/65536          2922 ns          2930 ns        1.0x
rng::fill_n(vector<int>)/1048576       79739 ns         79742 ns        1.0x
```

#### `fill`

```
--------------------------------------------------------------------------
Benchmark                              Before            After     Speedup
--------------------------------------------------------------------------
std::fill(deque<int>)/32              13.7 ns          2.45 ns        5.6x
std::fill(deque<int>)/50              21.7 ns          4.57 ns        4.7x
std::fill(deque<int>)/1024             367 ns          38.5 ns        9.5x
std::fill(deque<int>)/8192            2896 ns           247 ns       11.7x
std::fill(deque<int>)/65536          23723 ns          2907 ns        8.2x
std::fill(deque<int>)/1048576       379043 ns         79885 ns        4.7x
rng::fill(deque<int>)/32              13.6 ns          2.70 ns        5.0x
rng::fill(deque<int>)/50              23.4 ns          3.94 ns        5.9x
rng::fill(deque<int>)/1024             377 ns          37.9 ns        9.9x
rng::fill(deque<int>)/8192            2914 ns           286 ns       10.2x
rng::fill(deque<int>)/65536          23612 ns          2939 ns        8.0x
rng::fill(deque<int>)/1048576       379841 ns         80079 ns        4.7x
std::fill(vector<int>)/32             1.99 ns          1.79 ns        1.1x
std::fill(vector<int>)/50             3.05 ns          3.06 ns        1.0x
std::fill(vector<int>)/1024           37.6 ns          38.0 ns        1.0x
std::fill(vector<int>)/8192            255 ns           257 ns        1.0x
std::fill(vector<int>)/65536          2966 ns          2981 ns        1.0x
std::fill(vector<int>)/1048576       78300 ns         80348 ns        1.0x
rng::fill(vector<int>)/32             1.77 ns          1.75 ns        1.0x
rng::fill(vector<int>)/50             4.85 ns          2.31 ns        2.1x
rng::fill(vector<int>)/1024           39.6 ns          36.1 ns        1.1x
rng::fill(vector<int>)/8192            238 ns           251 ns        0.9x
rng::fill(vector<int>)/65536          2941 ns          2918 ns        1.0x
rng::fill(vector<int>)/1048576       80497 ns         80442 ns        1.0x
```

---------

Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Co-authored-by: A. Jiang <de34@live.cn>
 2025-10-17 07:41:24 +08:00
Louis Dionne
9783f28cbb
[libc++] Format the code base (#74334) 
This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmarks, the test suite and remaining parts of the code. I'm
splitting this one into its own patch so the diff is a bit easier to
review.

This patch was generated with:

   find libcxx/include libcxx/src -type f \
      | grep -v 'module.modulemap.in' \
      | grep -v 'CMakeLists.txt' \
      | grep -v 'README.txt' \
      | grep -v 'libcxx.imp' \
      | grep -v '__config_site.in' \
      | xargs clang-format -i

A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh
to help resolve merge and rebase issues across these formatting changes.

[1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
 2023-12-18 14:01:33 -05:00
Louis Dionne
77a00c0d54
[libc++] Replace uses of _VSTD:: by std:: (#74331) 
As part of the upcoming clang-formatting of libc++, this patch performs
the long desired removal of the _VSTD macro.

See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
for the clang-format proposal.
 2023-12-05 11:19:15 -05:00
Louis Dionne
4c19854222
[libc++] Rename _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI (#74095) 
In preparation for running clang-format on the whole code base, we are
also removing mentions of the legacy _LIBCPP_INLINE_VISIBILITY macro in
favor of the newer _LIBCPP_HIDE_FROM_ABI.

We're still leaving the definition of _LIBCPP_INLINE_VISIBILITY to avoid
creating needless breakage in case some older patches are checked-in
with mentions of the old macro. After we branch for LLVM 18, we can do
another pass to clean up remaining uses of the macro that might have
gotten introduced by mistake (if any) and remove the macro itself at the
same time. This is just a minor convenience to smooth out the transition
as much as possible.

See
https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
for the clang-format proposal.
 2023-12-04 10:25:14 -05:00
Nikolas Klauser
e698c59504 [libc++] Granularize <type_traits> includes in <algorithm> 
Reviewed By: Mordante, #libc

Spies: libcxx-commits, wenlei

Differential Revision: https://reviews.llvm.org/D140673
 2023-02-13 13:21:25 +01:00
Nikolas Klauser
5146b57b40 [libc++][NFC] Rename the constexpr macros 
This was discussed on Discord with the consensus that we should rename the macros.

Reviewed By: ldionne, Mordante, var-const, avogelsgesang, jloser, #libc

Spies: libcxx-commits

Differential Revision: https://reviews.llvm.org/D131498
 2022-08-19 15:35:02 +02:00
Nikolas Klauser
98d3d5b5da [libc++] Implement P1004R2 (constexpr std::vector) 
Reviewed By: #libc, ldionne

Spies: mgorny, var-const, ormris, philnik, miscco, hiraditya, steven_wu, jkorous, ldionne, christof, libcxx-commits

Differential Revision: https://reviews.llvm.org/D68365
 2022-07-27 20:26:44 +02:00
Nikolas Klauser
b48c5010a4 [libc++] Make parameter names consistent and enforce the naming style using readability-identifier-naming 
Ensure that parameter names have the style `__lower_case`

Reviewed By: ldionne, #libc

Spies: aheejin, sstefan1, libcxx-commits, miyuki

Differential Revision: https://reviews.llvm.org/D129051
 2022-07-08 18:17:47 +02:00
Louis Dionne
368faacac7 [libc++] Revert "Protect users from relying on detail headers" & related changes 
This commit reverts 5aaefa51 (and also partly 7f285f48e77 and b6d75682f9,
which were related to the original commit). As landed, 5aaefa51 had
unintended consequences on some downstream bots and didn't have proper
coverage upstream due to a few subtle things. Implementing this is
something we should do in libc++, however we'll first need to address
a few issues listed in https://reviews.llvm.org/D106124#3349710.

Differential Revision: https://reviews.llvm.org/D120683
 2022-03-01 08:20:24 -05:00
Christopher Di Bella
5aaefa510e [libcxx][modules] protects users from relying on detail headers 
libc++ has started splicing standard library headers into much more
fine-grained content for maintainability. It's very likely that outdated
and naive tooling (some of which is outside of LLVM's scope) will
suggest users include things such as <__ranges/access.h> instead of
<ranges>, and Hyrum's law suggests that users will eventually begin to
rely on this without the help of tooling. As such, this commit
intends to protect users from themselves, by making it a hard error for
anyone outside of the standard library to include libc++ detail headers.

Differential Revision: https://reviews.llvm.org/D106124
 2022-02-26 09:00:25 +00:00
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
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
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 7ed7d4ccb899, which was reverted in 692d7166f771
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 7ed7d4ccb8991e2b5b95334b508f8cec2faee737 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