| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[libc++] Remove some unused includes (#120219) | 1 年前 | |
[libc++] Forward std::all_of and std::none_of to std::any_of (#167670) This allows propagating optimizations to different algorithms by just optimizing the lowest one. This is especially relevant now that we start optimizing how we're iterating through ranges (e.g. the segmented iterator optimizations) and adding assumptions so the compier can better leverage semantics guaranteed by the standard (e.g. __builtin_assume_dereferenceable). | 8 个月前 | |
| 1 年前 | ||
[libc++] Remove some unused includes (#120219) | 1 年前 | |
[libc++] Remove _LIBCPP_DISABLE_NODISCARD_EXTENSIONS and refactor the tests (#87094) This also adds a few tests that were missing. | 2 年前 | |
| 9 个月前 | ||
[libc++] Put _LIBCPP_NODEBUG on all internal aliases (#118710) This significantly reduces the amount of debug information generated for codebases using libc++, without hurting the debugging experience. | 1 年前 | |
[libc++] Make the naming of the iterator_traits aliases consistent (#161661) This renames all the iterator_traits alises to be __iterator_<type-name>. e.g iterator_traits<T>::value_type will be __iterator_value_type<T>. | 9 个月前 | |
[libc++] Make the naming of the iterator_traits aliases consistent (#161661) This renames all the iterator_traits alises to be __iterator_<type-name>. e.g iterator_traits<T>::value_type will be __iterator_value_type<T>. | 9 个月前 | |
| 1 年前 | ||
[libc++] Remove _AlgPolicy from std::copy and algorithms using std::copy (#115887) std::copy doesn't use the _AlgPolicy for anything other than calling itself with it, so we can just remove the argument. This also removes the need in a few other algorithms which had an _AlgPolicy argument only to call copy. | 1 年前 | |
[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 | 2 年前 | |
[libc++] Make the naming of the iterator_traits aliases consistent (#161661) This renames all the iterator_traits alises to be __iterator_<type-name>. e.g iterator_traits<T>::value_type will be __iterator_value_type<T>. | 9 个月前 | |
| 1 年前 | ||
[libc++] Fix {std, ranges}::equal for vector<bool> with small storage types (#130394) The current implementation of {std, ranges}::equal fails to correctly compare vector<bool>s when the underlying storage type is smaller than int (e.g., unsigned char, unsigned short, uint8_t and uint16_t). See [demo](https://godbolt.org/z/j4s87s6b3)). The problem arises due to integral promotions on the intermediate bitwise operations, leading to incorrect final equality comparison results. This patch fixes the issue by ensuring that {std, ranges}::equal operate properly for both aligned and unaligned bits. Fixes #126369. | 1 年前 | |
[libc++] Remove some unused includes (#120219) | 1 年前 | |
[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. | 8 个月前 | |
[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. | 8 个月前 | |
[libc++] Avoid transitive inclusion for <__algorithm/find.h> (#162508) Currently, size_t and __libcpp_is_constant_evaluated are obtained by transitive inclusion in <__algorithm/find.h> when <cwchar> is not included. This broke module build when _LIBCPP_HAS_WIDE_CHARACTERS is 1 and caused CI failure. We should explicitly include the corresponding internal headers. | 9 个月前 | |
[libc++] Remove some unused includes (#120219) | 1 年前 | |
[libc++] Remove some unused includes (#120219) | 1 年前 | |
[libc++][NFC] Use [[__nodiscard__]] unconditionally (#80454) __has_cpp_attribute(__nodiscard__) is always true now, so we might as well replace _LIBCPP_NODISCARD. It's one less macro that can result in bad diagnostics. | 1 年前 | |
[libc++][NFC] Use [[__nodiscard__]] unconditionally (#80454) __has_cpp_attribute(__nodiscard__) is always true now, so we might as well replace _LIBCPP_NODISCARD. It's one less macro that can result in bad diagnostics. | 1 年前 | |
[libc++] Optimize std::find for segmented iterators (#67224) -------------------------------------------------------------------------- Benchmark old new -------------------------------------------------------------------------- bm_find<std::deque<char>>/1 6.06 ns 10.6 ns bm_find<std::deque<char>>/2 15.5 ns 10.6 ns bm_find<std::deque<char>>/3 19.0 ns 10.6 ns bm_find<std::deque<char>>/4 20.8 ns 10.6 ns bm_find<std::deque<char>>/5 22.0 ns 10.6 ns bm_find<std::deque<char>>/6 23.0 ns 10.5 ns bm_find<std::deque<char>>/7 24.8 ns 10.7 ns bm_find<std::deque<char>>/8 25.7 ns 10.6 ns bm_find<std::deque<char>>/16 28.3 ns 10.6 ns bm_find<std::deque<char>>/64 44.2 ns 27.0 ns bm_find<std::deque<char>>/512 133 ns 37.6 ns bm_find<std::deque<char>>/4096 867 ns 53.1 ns bm_find<std::deque<char>>/32768 6838 ns 160 ns bm_find<std::deque<char>>/262144 52897 ns 1495 ns bm_find<std::deque<char>>/1048576 215621 ns 6077 ns bm_find<std::deque<short>>/1 6.03 ns 6.28 ns bm_find<std::deque<short>>/2 15.8 ns 15.8 ns bm_find<std::deque<short>>/3 20.5 ns 20.3 ns bm_find<std::deque<short>>/4 21.0 ns 21.0 ns bm_find<std::deque<short>>/5 23.0 ns 22.1 ns bm_find<std::deque<short>>/6 22.6 ns 23.0 ns bm_find<std::deque<short>>/7 23.4 ns 23.7 ns bm_find<std::deque<short>>/8 24.4 ns 24.9 ns bm_find<std::deque<short>>/16 26.6 ns 27.2 ns bm_find<std::deque<short>>/64 43.2 ns 40.9 ns bm_find<std::deque<short>>/512 124 ns 90.7 ns bm_find<std::deque<short>>/4096 845 ns 525 ns bm_find<std::deque<short>>/32768 7273 ns 3194 ns bm_find<std::deque<short>>/262144 53710 ns 24385 ns bm_find<std::deque<short>>/1048576 216086 ns 96195 ns bm_find<std::deque<int>>/1 6.03 ns 10.3 ns bm_find<std::deque<int>>/2 15.6 ns 10.3 ns bm_find<std::deque<int>>/3 19.1 ns 10.3 ns bm_find<std::deque<int>>/4 22.3 ns 10.3 ns bm_find<std::deque<int>>/5 23.5 ns 10.4 ns bm_find<std::deque<int>>/6 23.1 ns 10.3 ns bm_find<std::deque<int>>/7 23.7 ns 10.2 ns bm_find<std::deque<int>>/8 24.5 ns 10.2 ns bm_find<std::deque<int>>/16 27.9 ns 26.6 ns bm_find<std::deque<int>>/64 42.6 ns 32.2 ns bm_find<std::deque<int>>/512 123 ns 43.0 ns bm_find<std::deque<int>>/4096 874 ns 93.5 ns bm_find<std::deque<int>>/32768 7031 ns 751 ns bm_find<std::deque<int>>/262144 57723 ns 6169 ns bm_find<std::deque<int>>/1048576 230867 ns 35851 ns bm_ranges_find<std::deque<char>>/1 5.97 ns 10.6 ns bm_ranges_find<std::deque<char>>/2 16.0 ns 10.5 ns bm_ranges_find<std::deque<char>>/3 19.5 ns 10.5 ns bm_ranges_find<std::deque<char>>/4 21.1 ns 10.6 ns bm_ranges_find<std::deque<char>>/5 22.8 ns 10.5 ns bm_ranges_find<std::deque<char>>/6 22.8 ns 10.6 ns bm_ranges_find<std::deque<char>>/7 23.4 ns 10.8 ns bm_ranges_find<std::deque<char>>/8 24.1 ns 10.5 ns bm_ranges_find<std::deque<char>>/16 26.9 ns 10.6 ns bm_ranges_find<std::deque<char>>/64 50.2 ns 27.2 ns bm_ranges_find<std::deque<char>>/512 126 ns 38.3 ns bm_ranges_find<std::deque<char>>/4096 868 ns 53.8 ns bm_ranges_find<std::deque<char>>/32768 6695 ns 161 ns bm_ranges_find<std::deque<char>>/262144 54411 ns 1497 ns bm_ranges_find<std::deque<char>>/1048576 241699 ns 6042 ns bm_ranges_find<std::deque<short>>/1 6.39 ns 6.31 ns bm_ranges_find<std::deque<short>>/2 15.8 ns 15.9 ns bm_ranges_find<std::deque<short>>/3 19.0 ns 19.8 ns bm_ranges_find<std::deque<short>>/4 20.8 ns 20.9 ns bm_ranges_find<std::deque<short>>/5 21.8 ns 22.1 ns bm_ranges_find<std::deque<short>>/6 23.0 ns 23.0 ns bm_ranges_find<std::deque<short>>/7 23.2 ns 23.9 ns bm_ranges_find<std::deque<short>>/8 23.7 ns 24.4 ns bm_ranges_find<std::deque<short>>/16 26.6 ns 26.8 ns bm_ranges_find<std::deque<short>>/64 43.4 ns 39.7 ns bm_ranges_find<std::deque<short>>/512 131 ns 90.5 ns bm_ranges_find<std::deque<short>>/4096 851 ns 523 ns bm_ranges_find<std::deque<short>>/32768 7370 ns 3166 ns bm_ranges_find<std::deque<short>>/262144 60778 ns 24814 ns bm_ranges_find<std::deque<short>>/1048576 229288 ns 99273 ns bm_ranges_find<std::deque<int>>/1 6.43 ns 10.2 ns bm_ranges_find<std::deque<int>>/2 16.6 ns 10.2 ns bm_ranges_find<std::deque<int>>/3 19.6 ns 10.2 ns bm_ranges_find<std::deque<int>>/4 21.0 ns 10.2 ns bm_ranges_find<std::deque<int>>/5 21.9 ns 10.4 ns bm_ranges_find<std::deque<int>>/6 22.7 ns 10.2 ns bm_ranges_find<std::deque<int>>/7 23.9 ns 10.2 ns bm_ranges_find<std::deque<int>>/8 23.8 ns 10.2 ns bm_ranges_find<std::deque<int>>/16 27.2 ns 27.1 ns bm_ranges_find<std::deque<int>>/64 42.4 ns 32.4 ns bm_ranges_find<std::deque<int>>/512 122 ns 43.0 ns bm_ranges_find<std::deque<int>>/4096 895 ns 93.7 ns bm_ranges_find<std::deque<int>>/32768 6890 ns 756 ns bm_ranges_find<std::deque<int>>/262144 54025 ns 6102 ns bm_ranges_find<std::deque<int>>/1048576 221558 ns 32783 ns | 2 年前 | |
[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. | 8 个月前 | |
[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. | 8 个月前 | |
[libc++][NFC] Make __is_segmented_iterator a variable template (#149976) | 1 年前 | |
[libc++] Introduce __for_each_segment and use it in copy/move This simplifies the code inside copy/move and makes it easier to apply the optimization to other algorithms. Reviewed By: ldionne, Mordante, #libc Spies: arichardson, libcxx-commits Differential Revision: https://reviews.llvm.org/D151265 | 3 年前 | |
[libcxx] Optimize std::generate for segmented iterators (#163006) Part of #102817. This patch attempts to optimize the performance of std::generate for segmented iterators. Below are the benchmark numbers from libcxx\test\benchmarks\algorithms\modifying\generate.bench.cpp. Test cases that use segmented iterators have also been added. - before std::generate(deque<int>)/32 194 ns 193 ns 3733333 std::generate(deque<int>)/50 276 ns 276 ns 2488889 std::generate(deque<int>)/1024 5096 ns 5022 ns 112000 std::generate(deque<int>)/8192 40806 ns 40806 ns 17231 - after std::generate(deque<int>)/32 106 ns 105 ns 6400000 std::generate(deque<int>)/50 139 ns 138 ns 4977778 std::generate(deque<int>)/1024 2713 ns 2699 ns 248889 std::generate(deque<int>)/8192 18983 ns 19252 ns 37333 --------- Co-authored-by: A. Jiang <de34@live.cn> | 9 个月前 | |
[libcxx] Optimize rng::generate_n for segmented iterators (#165280) Part of #102817. This patch optimizes rng::generate_n for segmented iterators by forwarding the implementation directly to std::generate_n. - before rng::generate_n(deque<int>)/32 21.7 ns 22.0 ns 32000000 rng::generate_n(deque<int>)/50 30.8 ns 30.7 ns 22400000 rng::generate_n(deque<int>)/1024 492 ns 488 ns 1120000 rng::generate_n(deque<int>)/8192 3938 ns 3924 ns 179200 - after rng::generate_n(deque<int>)/32 11.0 ns 11.0 ns 64000000 rng::generate_n(deque<int>)/50 16.2 ns 16.1 ns 40727273 rng::generate_n(deque<int>)/1024 292 ns 286 ns 2240000 rng::generate_n(deque<int>)/8192 2291 ns 2302 ns 298667 | 9 个月前 | |
[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 | 2 年前 | |
[libc++] Fix missing and incorrect push/pop macros (#79204) We recently noticed that the unwrap_iter.h file was pushing macros, but it was pushing them again instead of popping them at the end of the file. This led to libc++ basically swallowing any custom definition of these macros in user code: #define min HELLO #include <algorithm> // min is not HELLO anymore, it's not defined While investigating this issue, I noticed that our push/pop pragmas were actually entirely wrong too. Indeed, instead of pushing macros like move, we'd push move(int, int) in the pragma, which is not a valid macro name. As a result, we would not actually push macros like move -- instead we'd simply undefine them. This led to the following code not working: #define move HELLO #include <algorithm> // move is not HELLO anymore Fixing the pragma push/pop incantations led to a cascade of issues because we use identifiers like move in a large number of places, and all of these headers would now need to do the push/pop dance. This patch fixes all these issues. First, it adds a check that we don't swallow important names like min, max, move or refresh as explained above. This is done by augmenting the existing system_reserved_names.gen.py test to also check that the macros are what we expect after including each header. Second, it fixes the push/pop pragmas to work properly and adds missing pragmas to all the files I could detect a failure in via the newly added test. rdar://121365472 | 2 年前 | |
[libc++] Fix missing and incorrect push/pop macros (#79204) We recently noticed that the unwrap_iter.h file was pushing macros, but it was pushing them again instead of popping them at the end of the file. This led to libc++ basically swallowing any custom definition of these macros in user code: #define min HELLO #include <algorithm> // min is not HELLO anymore, it's not defined While investigating this issue, I noticed that our push/pop pragmas were actually entirely wrong too. Indeed, instead of pushing macros like move, we'd push move(int, int) in the pragma, which is not a valid macro name. As a result, we would not actually push macros like move -- instead we'd simply undefine them. This led to the following code not working: #define move HELLO #include <algorithm> // move is not HELLO anymore Fixing the pragma push/pop incantations led to a cascade of issues because we use identifiers like move in a large number of places, and all of these headers would now need to do the push/pop dance. This patch fixes all these issues. First, it adds a check that we don't swallow important names like min, max, move or refresh as explained above. This is done by augmenting the existing system_reserved_names.gen.py test to also check that the macros are what we expect after including each header. Second, it fixes the push/pop pragmas to work properly and adds missing pragmas to all the files I could detect a failure in via the newly added test. rdar://121365472 | 2 年前 | |
[libc++] Fix missing and incorrect push/pop macros (#79204) We recently noticed that the unwrap_iter.h file was pushing macros, but it was pushing them again instead of popping them at the end of the file. This led to libc++ basically swallowing any custom definition of these macros in user code: #define min HELLO #include <algorithm> // min is not HELLO anymore, it's not defined While investigating this issue, I noticed that our push/pop pragmas were actually entirely wrong too. Indeed, instead of pushing macros like move, we'd push move(int, int) in the pragma, which is not a valid macro name. As a result, we would not actually push macros like move -- instead we'd simply undefine them. This led to the following code not working: #define move HELLO #include <algorithm> // move is not HELLO anymore Fixing the pragma push/pop incantations led to a cascade of issues because we use identifiers like move in a large number of places, and all of these headers would now need to do the push/pop dance. This patch fixes all these issues. First, it adds a check that we don't swallow important names like min, max, move or refresh as explained above. This is done by augmenting the existing system_reserved_names.gen.py test to also check that the macros are what we expect after including each header. Second, it fixes the push/pop pragmas to work properly and adds missing pragmas to all the files I could detect a failure in via the newly added test. rdar://121365472 | 2 年前 | |
[libc++] Fix missing and incorrect push/pop macros (#79204) We recently noticed that the unwrap_iter.h file was pushing macros, but it was pushing them again instead of popping them at the end of the file. This led to libc++ basically swallowing any custom definition of these macros in user code: #define min HELLO #include <algorithm> // min is not HELLO anymore, it's not defined While investigating this issue, I noticed that our push/pop pragmas were actually entirely wrong too. Indeed, instead of pushing macros like move, we'd push move(int, int) in the pragma, which is not a valid macro name. As a result, we would not actually push macros like move -- instead we'd simply undefine them. This led to the following code not working: #define move HELLO #include <algorithm> // move is not HELLO anymore Fixing the pragma push/pop incantations led to a cascade of issues because we use identifiers like move in a large number of places, and all of these headers would now need to do the push/pop dance. This patch fixes all these issues. First, it adds a check that we don't swallow important names like min, max, move or refresh as explained above. This is done by augmenting the existing system_reserved_names.gen.py test to also check that the macros are what we expect after including each header. Second, it fixes the push/pop pragmas to work properly and adds missing pragmas to all the files I could detect a failure in via the newly added test. rdar://121365472 | 2 年前 | |
[libc++] Fix missing and incorrect push/pop macros (#79204) We recently noticed that the unwrap_iter.h file was pushing macros, but it was pushing them again instead of popping them at the end of the file. This led to libc++ basically swallowing any custom definition of these macros in user code: #define min HELLO #include <algorithm> // min is not HELLO anymore, it's not defined While investigating this issue, I noticed that our push/pop pragmas were actually entirely wrong too. Indeed, instead of pushing macros like move, we'd push move(int, int) in the pragma, which is not a valid macro name. As a result, we would not actually push macros like move -- instead we'd simply undefine them. This led to the following code not working: #define move HELLO #include <algorithm> // move is not HELLO anymore Fixing the pragma push/pop incantations led to a cascade of issues because we use identifiers like move in a large number of places, and all of these headers would now need to do the push/pop dance. This patch fixes all these issues. First, it adds a check that we don't swallow important names like min, max, move or refresh as explained above. This is done by augmenting the existing system_reserved_names.gen.py test to also check that the macros are what we expect after including each header. Second, it fixes the push/pop pragmas to work properly and adds missing pragmas to all the files I could detect a failure in via the newly added test. rdar://121365472 | 2 年前 | |
[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 | 2 年前 | |
[libc++] Remove some unused includes (#120219) | 1 年前 | |
[libc++] Implement part of P2562R1: constexpr std::inplace_merge (#129008) Drive-by: - Adds constexpr_random.h for pseudo-randomizing or shuffling in tests for constant evaluation. | 1 年前 | |
[libc++] Remove some unused includes (#120219) | 1 年前 | |
[libc++][NFC] Use [[__nodiscard__]] unconditionally (#80454) __has_cpp_attribute(__nodiscard__) is always true now, so we might as well replace _LIBCPP_NODISCARD. It's one less macro that can result in bad diagnostics. | 1 年前 | |
[libc++][NFC] Use [[__nodiscard__]] unconditionally (#80454) __has_cpp_attribute(__nodiscard__) is always true now, so we might as well replace _LIBCPP_NODISCARD. It's one less macro that can result in bad diagnostics. | 1 年前 | |
[libc++] Make the naming of the iterator_traits aliases consistent (#161661) This renames all the iterator_traits alises to be __iterator_<type-name>. e.g iterator_traits<T>::value_type will be __iterator_value_type<T>. | 9 个月前 | |
[libc++] Remove some unused includes (#120219) | 1 年前 | |
[libc++] Remove some unused includes (#120219) | 1 年前 | |
[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 | 2 年前 | |
[libc++] Put _LIBCPP_NODEBUG on all internal aliases (#118710) This significantly reduces the amount of debug information generated for codebases using libc++, without hurting the debugging experience. | 1 年前 | |
| 1 年前 | ||
[libc++] Make the naming of the iterator_traits aliases consistent (#161661) This renames all the iterator_traits alises to be __iterator_<type-name>. e.g iterator_traits<T>::value_type will be __iterator_value_type<T>. | 9 个月前 | |
[libc++] Remove some unused includes (#120219) | 1 年前 | |
[libc++] Make the naming of the iterator_traits aliases consistent (#161661) This renames all the iterator_traits alises to be __iterator_<type-name>. e.g iterator_traits<T>::value_type will be __iterator_value_type<T>. | 9 个月前 | |
[libc++] Define an internal API for std::invoke and friends (#116637) Currently we're using quite different internal names for the std::invoke family of type traits. This adds a layer around the current implementation to make it easier to understand when it is used and makes it easier to define multiple implementations of it. | 1 年前 | |
[libc++][NFC] Use [[__nodiscard__]] unconditionally (#80454) __has_cpp_attribute(__nodiscard__) is always true now, so we might as well replace _LIBCPP_NODISCARD. It's one less macro that can result in bad diagnostics. | 1 年前 | |
[libc++][NFC] Use [[__nodiscard__]] unconditionally (#80454) __has_cpp_attribute(__nodiscard__) is always true now, so we might as well replace _LIBCPP_NODISCARD. It's one less macro that can result in bad diagnostics. | 1 年前 | |
[libc++] Remove some unused includes (#120219) | 1 年前 | |
[libc++][NFC] Use [[__nodiscard__]] unconditionally (#80454) __has_cpp_attribute(__nodiscard__) is always true now, so we might as well replace _LIBCPP_NODISCARD. It's one less macro that can result in bad diagnostics. | 1 年前 | |
[libc++] Refactor ranges::{min, max, min_element, max_element} to use std::__min_element (#132418) Previously, ranges::min_element delegated to ranges::__min_element_impl, which duplicated the definition of std::__min_element. This patch updates ranges::min_element to directly call std::__min_element, which allows removing the redundant code in ranges::__min_element_impl. Upon removal of ranges::__min_element_impl, the other ranges algorithms ranges::{min,max,max_element}, which previously delegated to ranges::__min_element_impl, have been updated to call std::__min_element instead. This refactoring unifies the implementation across these algorithms, ensuring that future optimizations or maintenance work only need to be applied in one place. | 1 年前 | |
[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 | 2 年前 | |
[libc++][NFC] Use [[__nodiscard__]] unconditionally (#80454) __has_cpp_attribute(__nodiscard__) is always true now, so we might as well replace _LIBCPP_NODISCARD. It's one less macro that can result in bad diagnostics. | 1 年前 | |
[libc++][modules] Fix missing and incorrect includes (#108850) This patch adds a large number of missing includes in the libc++ headers and the test suite. Those were found as part of the effort to move towards a mostly monolithic top-level std module. | 1 年前 | |
[libc++] Make the naming of the iterator_traits aliases consistent (#161661) This renames all the iterator_traits alises to be __iterator_<type-name>. e.g iterator_traits<T>::value_type will be __iterator_value_type<T>. | 9 个月前 | |
[libc++] Make the naming of the iterator_traits aliases consistent (#161661) This renames all the iterator_traits alises to be __iterator_<type-name>. e.g iterator_traits<T>::value_type will be __iterator_value_type<T>. | 9 个月前 | |
[libc++] Make the naming of the iterator_traits aliases consistent (#161661) This renames all the iterator_traits alises to be __iterator_<type-name>. e.g iterator_traits<T>::value_type will be __iterator_value_type<T>. | 9 个月前 | |
[libc++] Fix missing and incorrect push/pop macros (#79204) We recently noticed that the unwrap_iter.h file was pushing macros, but it was pushing them again instead of popping them at the end of the file. This led to libc++ basically swallowing any custom definition of these macros in user code: #define min HELLO #include <algorithm> // min is not HELLO anymore, it's not defined While investigating this issue, I noticed that our push/pop pragmas were actually entirely wrong too. Indeed, instead of pushing macros like move, we'd push move(int, int) in the pragma, which is not a valid macro name. As a result, we would not actually push macros like move -- instead we'd simply undefine them. This led to the following code not working: #define move HELLO #include <algorithm> // move is not HELLO anymore Fixing the pragma push/pop incantations led to a cascade of issues because we use identifiers like move in a large number of places, and all of these headers would now need to do the push/pop dance. This patch fixes all these issues. First, it adds a check that we don't swallow important names like min, max, move or refresh as explained above. This is done by augmenting the existing system_reserved_names.gen.py test to also check that the macros are what we expect after including each header. Second, it fixes the push/pop pragmas to work properly and adds missing pragmas to all the files I could detect a failure in via the newly added test. rdar://121365472 | 2 年前 | |
[libc++] Forward std::all_of and std::none_of to std::any_of (#167670) This allows propagating optimizations to different algorithms by just optimizing the lowest one. This is especially relevant now that we start optimizing how we're iterating through ranges (e.g. the segmented iterator optimizations) and adding assumptions so the compier can better leverage semantics guaranteed by the standard (e.g. __builtin_assume_dereferenceable). | 8 个月前 | |
[libc++] Fix missing and incorrect push/pop macros (#79204) We recently noticed that the unwrap_iter.h file was pushing macros, but it was pushing them again instead of popping them at the end of the file. This led to libc++ basically swallowing any custom definition of these macros in user code: #define min HELLO #include <algorithm> // min is not HELLO anymore, it's not defined While investigating this issue, I noticed that our push/pop pragmas were actually entirely wrong too. Indeed, instead of pushing macros like move, we'd push move(int, int) in the pragma, which is not a valid macro name. As a result, we would not actually push macros like move -- instead we'd simply undefine them. This led to the following code not working: #define move HELLO #include <algorithm> // move is not HELLO anymore Fixing the pragma push/pop incantations led to a cascade of issues because we use identifiers like move in a large number of places, and all of these headers would now need to do the push/pop dance. This patch fixes all these issues. First, it adds a check that we don't swallow important names like min, max, move or refresh as explained above. This is done by augmenting the existing system_reserved_names.gen.py test to also check that the macros are what we expect after including each header. Second, it fixes the push/pop pragmas to work properly and adds missing pragmas to all the files I could detect a failure in via the newly added test. rdar://121365472 | 2 年前 | |
[libc++] Implement ranges::iota (#68494) # Overview As a disclaimer, this is my first PR to LLVM and while I've tried to ensure I've followed the LLVM and libc++ contributing guidelines, there's probably a good chance I missed something. If I have, just let me know and I'll try to correct it as soon as I can. This PR implements std::ranges::iota and std::ranges::out_value_result outlined in [P2440r1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2440r1.html). As outlined in the paper above, I've: - Implemented out_value_result and added to <algorithm> - Added out_value_result, iota_result, and two overloads of iota to std::ranges in <numeric> - Updated the version macro __cpp_lib_ranges_iota in <version> I've also added tests for ranges::iota and ranges::out_value_result. Lastly, I added those structs to the appropriate module files. Partially implements #105184 EDIT: Forgot to mention in the original post, thanks to @hawkinsw for taking a look at a preliminary version of this PR! # TODOs - [x] Updating the range [status doc](https://github.com/jamesETsmith/llvm-project/blob/main/libcxx/docs/Status/RangesMajorFeatures.csv) - [x] Ensure all comments from https://reviews.llvm.org/D121436 are addressed here - [X] EDIT (I'll do this in a separate PR). ~~I'm open to implementing the rest of P2440r1 (ranges::shift_left and ranges::shift_right) if that's ok, I just wanted to get feedback on ranges::iota first~~ - [x] I've been having trouble building the modules locally and want to make sure that's working properly Closes: #134060 | 1 年前 | |
[libc++] Improve the performance of std::make_heap a bit (#154092) Apple M4: ----------------------------------------------------------------------------------------------------- Benchmark old new ----------------------------------------------------------------------------------------------------- BM_MakeHeap_uint32_Random_1 0.285 ns 0.271 ns BM_MakeHeap_uint32_Random_4 2.09 ns 1.80 ns BM_MakeHeap_uint32_Random_16 1.85 ns 1.83 ns BM_MakeHeap_uint32_Random_64 1.92 ns 1.50 ns BM_MakeHeap_uint32_Random_256 2.10 ns 1.87 ns BM_MakeHeap_uint32_Random_1024 1.73 ns 1.86 ns BM_MakeHeap_uint32_Random_16384 2.17 ns 2.05 ns BM_MakeHeap_uint32_Random_262144 1.77 ns 1.77 ns BM_MakeHeap_uint32_Ascending_1 0.288 ns 0.277 ns BM_MakeHeap_uint32_Ascending_4 0.658 ns 0.481 ns BM_MakeHeap_uint32_Ascending_16 0.636 ns 0.637 ns BM_MakeHeap_uint32_Ascending_64 0.643 ns 0.601 ns BM_MakeHeap_uint32_Ascending_256 0.710 ns 0.636 ns BM_MakeHeap_uint32_Ascending_1024 0.747 ns 0.660 ns BM_MakeHeap_uint32_Ascending_16384 0.713 ns 0.633 ns BM_MakeHeap_uint32_Ascending_262144 0.769 ns 0.731 ns BM_MakeHeap_uint32_Descending_1 0.294 ns 0.280 ns BM_MakeHeap_uint32_Descending_4 0.379 ns 0.305 ns BM_MakeHeap_uint32_Descending_16 0.376 ns 0.268 ns BM_MakeHeap_uint32_Descending_64 0.358 ns 0.271 ns BM_MakeHeap_uint32_Descending_256 0.377 ns 0.284 ns BM_MakeHeap_uint32_Descending_1024 0.355 ns 0.267 ns BM_MakeHeap_uint32_Descending_16384 0.348 ns 0.248 ns BM_MakeHeap_uint32_Descending_262144 0.349 ns 0.247 ns BM_MakeHeap_uint32_SingleElement_1 0.292 ns 0.280 ns BM_MakeHeap_uint32_SingleElement_4 0.570 ns 0.332 ns BM_MakeHeap_uint32_SingleElement_16 0.635 ns 0.604 ns BM_MakeHeap_uint32_SingleElement_64 0.653 ns 0.567 ns BM_MakeHeap_uint32_SingleElement_256 0.703 ns 0.609 ns BM_MakeHeap_uint32_SingleElement_1024 0.737 ns 0.604 ns BM_MakeHeap_uint32_SingleElement_16384 0.699 ns 0.574 ns BM_MakeHeap_uint32_SingleElement_262144 0.803 ns 0.684 ns BM_MakeHeap_uint32_PipeOrgan_1 0.291 ns 0.284 ns BM_MakeHeap_uint32_PipeOrgan_4 0.588 ns 0.399 ns BM_MakeHeap_uint32_PipeOrgan_16 0.648 ns 1.12 ns BM_MakeHeap_uint32_PipeOrgan_64 0.662 ns 0.771 ns BM_MakeHeap_uint32_PipeOrgan_256 0.723 ns 0.672 ns BM_MakeHeap_uint32_PipeOrgan_1024 0.749 ns 0.674 ns BM_MakeHeap_uint32_PipeOrgan_16384 0.708 ns 0.638 ns BM_MakeHeap_uint32_PipeOrgan_262144 0.786 ns 0.743 ns BM_MakeHeap_uint32_Heap_1 0.298 ns 0.282 ns BM_MakeHeap_uint32_Heap_4 0.396 ns 0.308 ns BM_MakeHeap_uint32_Heap_16 0.377 ns 0.268 ns BM_MakeHeap_uint32_Heap_64 0.356 ns 0.271 ns BM_MakeHeap_uint32_Heap_256 0.378 ns 0.290 ns BM_MakeHeap_uint32_Heap_1024 0.356 ns 0.275 ns BM_MakeHeap_uint32_Heap_16384 0.348 ns 0.252 ns BM_MakeHeap_uint32_Heap_262144 0.347 ns 0.250 ns BM_MakeHeap_uint32_QuickSortAdversary_1 0.290 ns 0.284 ns BM_MakeHeap_uint32_QuickSortAdversary_4 0.627 ns 0.409 ns BM_MakeHeap_uint32_QuickSortAdversary_16 0.640 ns 0.653 ns BM_MakeHeap_uint32_QuickSortAdversary_64 0.577 ns 0.484 ns BM_MakeHeap_uint32_QuickSortAdversary_256 0.613 ns 0.521 ns BM_MakeHeap_uint32_QuickSortAdversary_1024 0.652 ns 0.514 ns BM_MakeHeap_uint32_QuickSortAdversary_16384 0.428 ns 0.308 ns BM_MakeHeap_uint32_QuickSortAdversary_262144 0.373 ns 0.261 ns BM_MakeHeap_uint64_Random_1 0.291 ns 0.281 ns BM_MakeHeap_uint64_Random_4 2.20 ns 1.97 ns BM_MakeHeap_uint64_Random_16 1.93 ns 1.70 ns BM_MakeHeap_uint64_Random_64 1.89 ns 1.48 ns BM_MakeHeap_uint64_Random_256 2.10 ns 1.99 ns BM_MakeHeap_uint64_Random_1024 1.41 ns 2.04 ns BM_MakeHeap_uint64_Random_16384 2.12 ns 1.83 ns BM_MakeHeap_uint64_Random_262144 1.83 ns 1.63 ns BM_MakeHeap_uint64_Ascending_1 0.288 ns 0.283 ns BM_MakeHeap_uint64_Ascending_4 0.624 ns 0.493 ns BM_MakeHeap_uint64_Ascending_16 0.648 ns 0.688 ns BM_MakeHeap_uint64_Ascending_64 0.671 ns 0.634 ns BM_MakeHeap_uint64_Ascending_256 0.739 ns 0.680 ns BM_MakeHeap_uint64_Ascending_1024 0.761 ns 0.698 ns BM_MakeHeap_uint64_Ascending_16384 0.740 ns 0.685 ns BM_MakeHeap_uint64_Ascending_262144 0.849 ns 0.837 ns BM_MakeHeap_uint64_Descending_1 0.304 ns 0.287 ns BM_MakeHeap_uint64_Descending_4 0.395 ns 0.312 ns BM_MakeHeap_uint64_Descending_16 0.374 ns 0.276 ns BM_MakeHeap_uint64_Descending_64 0.358 ns 0.272 ns BM_MakeHeap_uint64_Descending_256 0.389 ns 0.303 ns BM_MakeHeap_uint64_Descending_1024 0.361 ns 0.278 ns BM_MakeHeap_uint64_Descending_16384 0.352 ns 0.253 ns BM_MakeHeap_uint64_Descending_262144 0.350 ns 0.251 ns BM_MakeHeap_uint64_SingleElement_1 0.295 ns 0.285 ns BM_MakeHeap_uint64_SingleElement_4 0.569 ns 0.358 ns BM_MakeHeap_uint64_SingleElement_16 0.649 ns 0.652 ns BM_MakeHeap_uint64_SingleElement_64 0.673 ns 0.565 ns BM_MakeHeap_uint64_SingleElement_256 0.732 ns 0.651 ns BM_MakeHeap_uint64_SingleElement_1024 0.759 ns 0.632 ns BM_MakeHeap_uint64_SingleElement_16384 0.748 ns 0.614 ns BM_MakeHeap_uint64_SingleElement_262144 0.947 ns 0.797 ns BM_MakeHeap_uint64_PipeOrgan_1 0.295 ns 0.284 ns BM_MakeHeap_uint64_PipeOrgan_4 0.601 ns 0.496 ns BM_MakeHeap_uint64_PipeOrgan_16 0.655 ns 1.18 ns BM_MakeHeap_uint64_PipeOrgan_64 0.682 ns 0.803 ns BM_MakeHeap_uint64_PipeOrgan_256 0.759 ns 0.710 ns BM_MakeHeap_uint64_PipeOrgan_1024 0.759 ns 0.713 ns BM_MakeHeap_uint64_PipeOrgan_16384 0.739 ns 0.696 ns BM_MakeHeap_uint64_PipeOrgan_262144 0.870 ns 0.849 ns BM_MakeHeap_uint64_Heap_1 0.290 ns 0.284 ns BM_MakeHeap_uint64_Heap_4 0.413 ns 0.314 ns BM_MakeHeap_uint64_Heap_16 0.378 ns 0.277 ns BM_MakeHeap_uint64_Heap_64 0.362 ns 0.272 ns BM_MakeHeap_uint64_Heap_256 0.389 ns 0.303 ns BM_MakeHeap_uint64_Heap_1024 0.362 ns 0.283 ns BM_MakeHeap_uint64_Heap_16384 0.352 ns 0.253 ns BM_MakeHeap_uint64_Heap_262144 0.350 ns 0.251 ns BM_MakeHeap_uint64_QuickSortAdversary_1 0.293 ns 0.284 ns BM_MakeHeap_uint64_QuickSortAdversary_4 0.606 ns 0.494 ns BM_MakeHeap_uint64_QuickSortAdversary_16 0.645 ns 0.691 ns BM_MakeHeap_uint64_QuickSortAdversary_64 0.607 ns 0.511 ns BM_MakeHeap_uint64_QuickSortAdversary_256 0.641 ns 0.537 ns BM_MakeHeap_uint64_QuickSortAdversary_1024 0.657 ns 0.529 ns BM_MakeHeap_uint64_QuickSortAdversary_16384 0.435 ns 0.316 ns BM_MakeHeap_uint64_QuickSortAdversary_262144 0.382 ns 0.266 ns BM_MakeHeap_pair<uint32, uint32>_Random_1 0.297 ns 0.378 ns BM_MakeHeap_pair<uint32, uint32>_Random_4 2.80 ns 0.765 ns BM_MakeHeap_pair<uint32, uint32>_Random_16 2.92 ns 2.20 ns BM_MakeHeap_pair<uint32, uint32>_Random_64 3.17 ns 3.64 ns BM_MakeHeap_pair<uint32, uint32>_Random_256 3.44 ns 3.20 ns BM_MakeHeap_pair<uint32, uint32>_Random_1024 3.35 ns 3.64 ns BM_MakeHeap_pair<uint32, uint32>_Random_16384 3.22 ns 3.50 ns BM_MakeHeap_pair<uint32, uint32>_Random_262144 3.61 ns 3.46 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_1 0.291 ns 0.379 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_4 0.779 ns 0.436 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_16 0.943 ns 1.01 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_64 1.17 ns 1.26 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_256 1.38 ns 1.44 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_1024 1.37 ns 1.43 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_16384 1.29 ns 1.31 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_262144 1.37 ns 1.40 ns BM_MakeHeap_pair<uint32, uint32>_Descending_1 0.292 ns 0.382 ns BM_MakeHeap_pair<uint32, uint32>_Descending_4 0.440 ns 0.347 ns BM_MakeHeap_pair<uint32, uint32>_Descending_16 0.529 ns 0.520 ns BM_MakeHeap_pair<uint32, uint32>_Descending_64 0.540 ns 0.527 ns BM_MakeHeap_pair<uint32, uint32>_Descending_256 0.637 ns 0.583 ns BM_MakeHeap_pair<uint32, uint32>_Descending_1024 0.552 ns 0.513 ns BM_MakeHeap_pair<uint32, uint32>_Descending_16384 0.522 ns 0.488 ns BM_MakeHeap_pair<uint32, uint32>_Descending_262144 0.515 ns 0.492 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_1 0.299 ns 0.377 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_4 0.787 ns 0.474 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_16 1.07 ns 0.921 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_64 1.20 ns 1.15 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_256 1.30 ns 1.27 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_1024 1.30 ns 1.31 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_16384 1.29 ns 1.28 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_262144 1.37 ns 1.38 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_1 0.293 ns 0.385 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_4 0.677 ns 0.438 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_16 1.04 ns 1.00 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_64 1.20 ns 1.27 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_256 1.40 ns 1.43 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_1024 1.36 ns 1.43 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_16384 1.27 ns 1.31 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_262144 1.37 ns 1.41 ns BM_MakeHeap_pair<uint32, uint32>_Heap_1 0.292 ns 0.378 ns BM_MakeHeap_pair<uint32, uint32>_Heap_4 0.440 ns 0.380 ns BM_MakeHeap_pair<uint32, uint32>_Heap_16 0.560 ns 0.606 ns BM_MakeHeap_pair<uint32, uint32>_Heap_64 0.588 ns 0.573 ns BM_MakeHeap_pair<uint32, uint32>_Heap_256 0.632 ns 0.607 ns BM_MakeHeap_pair<uint32, uint32>_Heap_1024 0.598 ns 0.580 ns BM_MakeHeap_pair<uint32, uint32>_Heap_16384 0.576 ns 0.563 ns BM_MakeHeap_pair<uint32, uint32>_Heap_262144 0.572 ns 0.561 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_1 0.304 ns 0.379 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_4 0.823 ns 0.430 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_16 1.08 ns 1.03 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_64 1.18 ns 1.23 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_256 1.39 ns 1.43 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_1024 1.36 ns 1.42 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_16384 1.28 ns 1.32 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_262144 1.34 ns 1.37 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_1 0.276 ns 0.511 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_4 4.25 ns 1.96 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_16 4.84 ns 3.77 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_64 5.53 ns 4.93 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_256 5.30 ns 5.06 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_1024 5.29 ns 5.02 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_16384 5.53 ns 5.31 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_262144 5.49 ns 5.29 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_1 0.275 ns 0.443 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_4 1.22 ns 0.764 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_16 1.39 ns 1.49 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_64 1.66 ns 1.76 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_256 1.85 ns 1.99 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_1024 1.90 ns 2.02 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_16384 2.15 ns 2.27 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_262144 2.25 ns 2.37 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_1 0.274 ns 0.445 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_4 0.939 ns 0.520 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_16 1.02 ns 0.811 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_64 1.01 ns 0.941 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_256 1.03 ns 1.01 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_1024 0.969 ns 0.947 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_16384 0.882 ns 0.876 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_262144 0.893 ns 0.871 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_1 0.276 ns 0.443 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_4 1.34 ns 0.870 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_16 1.60 ns 1.59 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_64 1.91 ns 2.00 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_256 1.91 ns 2.08 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_1024 1.91 ns 2.10 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_16384 2.13 ns 2.35 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_262144 2.25 ns 2.48 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_1 0.275 ns 0.446 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_4 1.07 ns 0.671 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_16 1.36 ns 1.44 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_64 1.70 ns 1.80 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_256 1.88 ns 2.05 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_1024 1.92 ns 2.06 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_16384 2.11 ns 2.26 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_262144 2.18 ns 2.34 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_1 0.274 ns 0.441 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_4 0.938 ns 0.587 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_16 1.01 ns 0.873 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_64 1.08 ns 1.00 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_256 1.21 ns 1.18 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_1024 1.37 ns 1.29 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_16384 1.31 ns 1.26 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_262144 1.29 ns 1.25 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_1 0.275 ns 0.447 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_4 1.22 ns 0.764 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_16 1.35 ns 1.46 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_64 1.63 ns 1.73 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_256 1.83 ns 1.87 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_1024 1.81 ns 1.94 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_16384 2.06 ns 2.19 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_262144 2.14 ns 2.31 ns BM_MakeHeap_string_Random_1 0.289 ns 0.446 ns BM_MakeHeap_string_Random_4 7.43 ns 4.84 ns BM_MakeHeap_string_Random_16 9.73 ns 8.92 ns BM_MakeHeap_string_Random_64 11.5 ns 11.5 ns BM_MakeHeap_string_Random_256 12.6 ns 12.4 ns BM_MakeHeap_string_Random_1024 13.2 ns 13.2 ns BM_MakeHeap_string_Random_16384 15.4 ns 15.4 ns BM_MakeHeap_string_Random_262144 21.4 ns 21.5 ns BM_MakeHeap_string_Ascending_1 0.287 ns 0.447 ns BM_MakeHeap_string_Ascending_4 3.22 ns 2.44 ns BM_MakeHeap_string_Ascending_16 3.77 ns 3.62 ns BM_MakeHeap_string_Ascending_64 4.84 ns 5.17 ns BM_MakeHeap_string_Ascending_256 5.79 ns 6.04 ns BM_MakeHeap_string_Ascending_1024 5.93 ns 6.60 ns BM_MakeHeap_string_Ascending_16384 6.84 ns 7.25 ns BM_MakeHeap_string_Ascending_262144 13.5 ns 14.3 ns BM_MakeHeap_string_Descending_1 0.293 ns 0.447 ns BM_MakeHeap_string_Descending_4 2.61 ns 1.83 ns BM_MakeHeap_string_Descending_16 2.64 ns 2.60 ns BM_MakeHeap_string_Descending_64 2.75 ns 2.74 ns BM_MakeHeap_string_Descending_256 3.78 ns 3.57 ns BM_MakeHeap_string_Descending_1024 3.20 ns 3.51 ns BM_MakeHeap_string_Descending_16384 3.57 ns 3.85 ns BM_MakeHeap_string_Descending_262144 6.27 ns 6.39 ns BM_MakeHeap_string_SingleElement_1 0.291 ns 0.448 ns BM_MakeHeap_string_SingleElement_4 3.88 ns 2.71 ns BM_MakeHeap_string_SingleElement_16 5.08 ns 4.96 ns BM_MakeHeap_string_SingleElement_64 6.14 ns 6.29 ns BM_MakeHeap_string_SingleElement_256 6.13 ns 6.46 ns BM_MakeHeap_string_SingleElement_1024 5.98 ns 6.60 ns BM_MakeHeap_string_SingleElement_16384 5.88 ns 6.39 ns BM_MakeHeap_string_SingleElement_262144 9.95 ns 10.2 ns BM_MakeHeap_string_PipeOrgan_1 0.292 ns 0.447 ns BM_MakeHeap_string_PipeOrgan_4 2.97 ns 2.51 ns BM_MakeHeap_string_PipeOrgan_16 3.76 ns 3.91 ns BM_MakeHeap_string_PipeOrgan_64 4.89 ns 5.20 ns BM_MakeHeap_string_PipeOrgan_256 5.77 ns 6.09 ns BM_MakeHeap_string_PipeOrgan_1024 6.14 ns 6.40 ns BM_MakeHeap_string_PipeOrgan_16384 6.83 ns 7.32 ns BM_MakeHeap_string_PipeOrgan_262144 13.8 ns 14.6 ns BM_MakeHeap_string_Heap_1 0.288 ns 0.515 ns BM_MakeHeap_string_Heap_4 3.62 ns 4.20 ns BM_MakeHeap_string_Heap_16 5.36 ns 5.23 ns BM_MakeHeap_string_Heap_64 5.79 ns 5.38 ns BM_MakeHeap_string_Heap_256 5.70 ns 5.40 ns BM_MakeHeap_string_Heap_1024 5.78 ns 5.37 ns BM_MakeHeap_string_Heap_16384 6.09 ns 5.67 ns BM_MakeHeap_string_Heap_262144 6.37 ns 5.96 ns BM_MakeHeap_string_QuickSortAdversary_1 0.282 ns 0.448 ns BM_MakeHeap_string_QuickSortAdversary_4 7.45 ns 5.60 ns BM_MakeHeap_string_QuickSortAdversary_16 9.76 ns 8.85 ns BM_MakeHeap_string_QuickSortAdversary_64 11.5 ns 11.2 ns BM_MakeHeap_string_QuickSortAdversary_256 12.0 ns 11.8 ns BM_MakeHeap_string_QuickSortAdversary_1024 12.2 ns 12.0 ns BM_MakeHeap_string_QuickSortAdversary_16384 13.7 ns 13.6 ns BM_MakeHeap_string_QuickSortAdversary_262144 14.1 ns 14.8 ns BM_MakeHeap_float_Random_1 0.287 ns 0.287 ns BM_MakeHeap_float_Random_4 2.29 ns 2.60 ns BM_MakeHeap_float_Random_16 4.00 ns 2.48 ns BM_MakeHeap_float_Random_64 4.41 ns 1.92 ns BM_MakeHeap_float_Random_256 4.73 ns 2.05 ns BM_MakeHeap_float_Random_1024 4.90 ns 2.27 ns BM_MakeHeap_float_Random_16384 4.42 ns 2.27 ns BM_MakeHeap_float_Random_262144 4.72 ns 1.39 ns BM_MakeHeap_float_Ascending_1 0.291 ns 0.293 ns BM_MakeHeap_float_Ascending_4 0.633 ns 0.428 ns BM_MakeHeap_float_Ascending_16 0.638 ns 0.874 ns BM_MakeHeap_float_Ascending_64 0.614 ns 0.698 ns BM_MakeHeap_float_Ascending_256 0.663 ns 0.713 ns BM_MakeHeap_float_Ascending_1024 0.660 ns 0.761 ns BM_MakeHeap_float_Ascending_16384 0.628 ns 0.725 ns BM_MakeHeap_float_Ascending_262144 0.629 ns 0.814 ns BM_MakeHeap_float_Descending_1 0.290 ns 0.290 ns BM_MakeHeap_float_Descending_4 0.421 ns 0.316 ns BM_MakeHeap_float_Descending_16 0.302 ns 0.225 ns BM_MakeHeap_float_Descending_64 0.293 ns 0.212 ns BM_MakeHeap_float_Descending_256 0.314 ns 0.246 ns BM_MakeHeap_float_Descending_1024 0.300 ns 0.231 ns BM_MakeHeap_float_Descending_16384 0.308 ns 0.205 ns BM_MakeHeap_float_Descending_262144 0.309 ns 0.203 ns BM_MakeHeap_float_SingleElement_1 0.289 ns 0.292 ns BM_MakeHeap_float_SingleElement_4 0.569 ns 0.347 ns BM_MakeHeap_float_SingleElement_16 0.538 ns 0.825 ns BM_MakeHeap_float_SingleElement_64 0.585 ns 0.727 ns BM_MakeHeap_float_SingleElement_256 0.603 ns 0.708 ns BM_MakeHeap_float_SingleElement_1024 0.618 ns 0.760 ns BM_MakeHeap_float_SingleElement_16384 0.599 ns 0.726 ns BM_MakeHeap_float_SingleElement_262144 0.723 ns 0.820 ns BM_MakeHeap_float_PipeOrgan_1 0.289 ns 0.291 ns BM_MakeHeap_float_PipeOrgan_4 0.457 ns 0.420 ns BM_MakeHeap_float_PipeOrgan_16 0.670 ns 1.32 ns BM_MakeHeap_float_PipeOrgan_64 0.764 ns 0.889 ns BM_MakeHeap_float_PipeOrgan_256 0.793 ns 0.757 ns BM_MakeHeap_float_PipeOrgan_1024 0.755 ns 0.764 ns BM_MakeHeap_float_PipeOrgan_16384 0.723 ns 0.723 ns BM_MakeHeap_float_PipeOrgan_262144 0.654 ns 0.817 ns BM_MakeHeap_float_Heap_1 0.291 ns 0.289 ns BM_MakeHeap_float_Heap_4 0.388 ns 0.316 ns BM_MakeHeap_float_Heap_16 0.317 ns 0.225 ns BM_MakeHeap_float_Heap_64 0.353 ns 0.213 ns BM_MakeHeap_float_Heap_256 0.361 ns 0.246 ns BM_MakeHeap_float_Heap_1024 0.381 ns 0.233 ns BM_MakeHeap_float_Heap_16384 0.390 ns 0.205 ns BM_MakeHeap_float_Heap_262144 0.379 ns 0.202 ns BM_MakeHeap_float_QuickSortAdversary_1 0.295 ns 0.289 ns BM_MakeHeap_float_QuickSortAdversary_4 0.640 ns 0.422 ns BM_MakeHeap_float_QuickSortAdversary_16 0.658 ns 0.871 ns BM_MakeHeap_float_QuickSortAdversary_64 0.574 ns 0.659 ns BM_MakeHeap_float_QuickSortAdversary_256 0.631 ns 0.550 ns BM_MakeHeap_float_QuickSortAdversary_1024 0.617 ns 0.552 ns BM_MakeHeap_float_QuickSortAdversary_16384 0.424 ns 0.283 ns BM_MakeHeap_float_QuickSortAdversary_262144 0.386 ns 0.219 ns Fixes #120752 | 10 个月前 | |
[libc++] Improve the performance of std::make_heap a bit (#154092) Apple M4: ----------------------------------------------------------------------------------------------------- Benchmark old new ----------------------------------------------------------------------------------------------------- BM_MakeHeap_uint32_Random_1 0.285 ns 0.271 ns BM_MakeHeap_uint32_Random_4 2.09 ns 1.80 ns BM_MakeHeap_uint32_Random_16 1.85 ns 1.83 ns BM_MakeHeap_uint32_Random_64 1.92 ns 1.50 ns BM_MakeHeap_uint32_Random_256 2.10 ns 1.87 ns BM_MakeHeap_uint32_Random_1024 1.73 ns 1.86 ns BM_MakeHeap_uint32_Random_16384 2.17 ns 2.05 ns BM_MakeHeap_uint32_Random_262144 1.77 ns 1.77 ns BM_MakeHeap_uint32_Ascending_1 0.288 ns 0.277 ns BM_MakeHeap_uint32_Ascending_4 0.658 ns 0.481 ns BM_MakeHeap_uint32_Ascending_16 0.636 ns 0.637 ns BM_MakeHeap_uint32_Ascending_64 0.643 ns 0.601 ns BM_MakeHeap_uint32_Ascending_256 0.710 ns 0.636 ns BM_MakeHeap_uint32_Ascending_1024 0.747 ns 0.660 ns BM_MakeHeap_uint32_Ascending_16384 0.713 ns 0.633 ns BM_MakeHeap_uint32_Ascending_262144 0.769 ns 0.731 ns BM_MakeHeap_uint32_Descending_1 0.294 ns 0.280 ns BM_MakeHeap_uint32_Descending_4 0.379 ns 0.305 ns BM_MakeHeap_uint32_Descending_16 0.376 ns 0.268 ns BM_MakeHeap_uint32_Descending_64 0.358 ns 0.271 ns BM_MakeHeap_uint32_Descending_256 0.377 ns 0.284 ns BM_MakeHeap_uint32_Descending_1024 0.355 ns 0.267 ns BM_MakeHeap_uint32_Descending_16384 0.348 ns 0.248 ns BM_MakeHeap_uint32_Descending_262144 0.349 ns 0.247 ns BM_MakeHeap_uint32_SingleElement_1 0.292 ns 0.280 ns BM_MakeHeap_uint32_SingleElement_4 0.570 ns 0.332 ns BM_MakeHeap_uint32_SingleElement_16 0.635 ns 0.604 ns BM_MakeHeap_uint32_SingleElement_64 0.653 ns 0.567 ns BM_MakeHeap_uint32_SingleElement_256 0.703 ns 0.609 ns BM_MakeHeap_uint32_SingleElement_1024 0.737 ns 0.604 ns BM_MakeHeap_uint32_SingleElement_16384 0.699 ns 0.574 ns BM_MakeHeap_uint32_SingleElement_262144 0.803 ns 0.684 ns BM_MakeHeap_uint32_PipeOrgan_1 0.291 ns 0.284 ns BM_MakeHeap_uint32_PipeOrgan_4 0.588 ns 0.399 ns BM_MakeHeap_uint32_PipeOrgan_16 0.648 ns 1.12 ns BM_MakeHeap_uint32_PipeOrgan_64 0.662 ns 0.771 ns BM_MakeHeap_uint32_PipeOrgan_256 0.723 ns 0.672 ns BM_MakeHeap_uint32_PipeOrgan_1024 0.749 ns 0.674 ns BM_MakeHeap_uint32_PipeOrgan_16384 0.708 ns 0.638 ns BM_MakeHeap_uint32_PipeOrgan_262144 0.786 ns 0.743 ns BM_MakeHeap_uint32_Heap_1 0.298 ns 0.282 ns BM_MakeHeap_uint32_Heap_4 0.396 ns 0.308 ns BM_MakeHeap_uint32_Heap_16 0.377 ns 0.268 ns BM_MakeHeap_uint32_Heap_64 0.356 ns 0.271 ns BM_MakeHeap_uint32_Heap_256 0.378 ns 0.290 ns BM_MakeHeap_uint32_Heap_1024 0.356 ns 0.275 ns BM_MakeHeap_uint32_Heap_16384 0.348 ns 0.252 ns BM_MakeHeap_uint32_Heap_262144 0.347 ns 0.250 ns BM_MakeHeap_uint32_QuickSortAdversary_1 0.290 ns 0.284 ns BM_MakeHeap_uint32_QuickSortAdversary_4 0.627 ns 0.409 ns BM_MakeHeap_uint32_QuickSortAdversary_16 0.640 ns 0.653 ns BM_MakeHeap_uint32_QuickSortAdversary_64 0.577 ns 0.484 ns BM_MakeHeap_uint32_QuickSortAdversary_256 0.613 ns 0.521 ns BM_MakeHeap_uint32_QuickSortAdversary_1024 0.652 ns 0.514 ns BM_MakeHeap_uint32_QuickSortAdversary_16384 0.428 ns 0.308 ns BM_MakeHeap_uint32_QuickSortAdversary_262144 0.373 ns 0.261 ns BM_MakeHeap_uint64_Random_1 0.291 ns 0.281 ns BM_MakeHeap_uint64_Random_4 2.20 ns 1.97 ns BM_MakeHeap_uint64_Random_16 1.93 ns 1.70 ns BM_MakeHeap_uint64_Random_64 1.89 ns 1.48 ns BM_MakeHeap_uint64_Random_256 2.10 ns 1.99 ns BM_MakeHeap_uint64_Random_1024 1.41 ns 2.04 ns BM_MakeHeap_uint64_Random_16384 2.12 ns 1.83 ns BM_MakeHeap_uint64_Random_262144 1.83 ns 1.63 ns BM_MakeHeap_uint64_Ascending_1 0.288 ns 0.283 ns BM_MakeHeap_uint64_Ascending_4 0.624 ns 0.493 ns BM_MakeHeap_uint64_Ascending_16 0.648 ns 0.688 ns BM_MakeHeap_uint64_Ascending_64 0.671 ns 0.634 ns BM_MakeHeap_uint64_Ascending_256 0.739 ns 0.680 ns BM_MakeHeap_uint64_Ascending_1024 0.761 ns 0.698 ns BM_MakeHeap_uint64_Ascending_16384 0.740 ns 0.685 ns BM_MakeHeap_uint64_Ascending_262144 0.849 ns 0.837 ns BM_MakeHeap_uint64_Descending_1 0.304 ns 0.287 ns BM_MakeHeap_uint64_Descending_4 0.395 ns 0.312 ns BM_MakeHeap_uint64_Descending_16 0.374 ns 0.276 ns BM_MakeHeap_uint64_Descending_64 0.358 ns 0.272 ns BM_MakeHeap_uint64_Descending_256 0.389 ns 0.303 ns BM_MakeHeap_uint64_Descending_1024 0.361 ns 0.278 ns BM_MakeHeap_uint64_Descending_16384 0.352 ns 0.253 ns BM_MakeHeap_uint64_Descending_262144 0.350 ns 0.251 ns BM_MakeHeap_uint64_SingleElement_1 0.295 ns 0.285 ns BM_MakeHeap_uint64_SingleElement_4 0.569 ns 0.358 ns BM_MakeHeap_uint64_SingleElement_16 0.649 ns 0.652 ns BM_MakeHeap_uint64_SingleElement_64 0.673 ns 0.565 ns BM_MakeHeap_uint64_SingleElement_256 0.732 ns 0.651 ns BM_MakeHeap_uint64_SingleElement_1024 0.759 ns 0.632 ns BM_MakeHeap_uint64_SingleElement_16384 0.748 ns 0.614 ns BM_MakeHeap_uint64_SingleElement_262144 0.947 ns 0.797 ns BM_MakeHeap_uint64_PipeOrgan_1 0.295 ns 0.284 ns BM_MakeHeap_uint64_PipeOrgan_4 0.601 ns 0.496 ns BM_MakeHeap_uint64_PipeOrgan_16 0.655 ns 1.18 ns BM_MakeHeap_uint64_PipeOrgan_64 0.682 ns 0.803 ns BM_MakeHeap_uint64_PipeOrgan_256 0.759 ns 0.710 ns BM_MakeHeap_uint64_PipeOrgan_1024 0.759 ns 0.713 ns BM_MakeHeap_uint64_PipeOrgan_16384 0.739 ns 0.696 ns BM_MakeHeap_uint64_PipeOrgan_262144 0.870 ns 0.849 ns BM_MakeHeap_uint64_Heap_1 0.290 ns 0.284 ns BM_MakeHeap_uint64_Heap_4 0.413 ns 0.314 ns BM_MakeHeap_uint64_Heap_16 0.378 ns 0.277 ns BM_MakeHeap_uint64_Heap_64 0.362 ns 0.272 ns BM_MakeHeap_uint64_Heap_256 0.389 ns 0.303 ns BM_MakeHeap_uint64_Heap_1024 0.362 ns 0.283 ns BM_MakeHeap_uint64_Heap_16384 0.352 ns 0.253 ns BM_MakeHeap_uint64_Heap_262144 0.350 ns 0.251 ns BM_MakeHeap_uint64_QuickSortAdversary_1 0.293 ns 0.284 ns BM_MakeHeap_uint64_QuickSortAdversary_4 0.606 ns 0.494 ns BM_MakeHeap_uint64_QuickSortAdversary_16 0.645 ns 0.691 ns BM_MakeHeap_uint64_QuickSortAdversary_64 0.607 ns 0.511 ns BM_MakeHeap_uint64_QuickSortAdversary_256 0.641 ns 0.537 ns BM_MakeHeap_uint64_QuickSortAdversary_1024 0.657 ns 0.529 ns BM_MakeHeap_uint64_QuickSortAdversary_16384 0.435 ns 0.316 ns BM_MakeHeap_uint64_QuickSortAdversary_262144 0.382 ns 0.266 ns BM_MakeHeap_pair<uint32, uint32>_Random_1 0.297 ns 0.378 ns BM_MakeHeap_pair<uint32, uint32>_Random_4 2.80 ns 0.765 ns BM_MakeHeap_pair<uint32, uint32>_Random_16 2.92 ns 2.20 ns BM_MakeHeap_pair<uint32, uint32>_Random_64 3.17 ns 3.64 ns BM_MakeHeap_pair<uint32, uint32>_Random_256 3.44 ns 3.20 ns BM_MakeHeap_pair<uint32, uint32>_Random_1024 3.35 ns 3.64 ns BM_MakeHeap_pair<uint32, uint32>_Random_16384 3.22 ns 3.50 ns BM_MakeHeap_pair<uint32, uint32>_Random_262144 3.61 ns 3.46 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_1 0.291 ns 0.379 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_4 0.779 ns 0.436 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_16 0.943 ns 1.01 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_64 1.17 ns 1.26 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_256 1.38 ns 1.44 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_1024 1.37 ns 1.43 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_16384 1.29 ns 1.31 ns BM_MakeHeap_pair<uint32, uint32>_Ascending_262144 1.37 ns 1.40 ns BM_MakeHeap_pair<uint32, uint32>_Descending_1 0.292 ns 0.382 ns BM_MakeHeap_pair<uint32, uint32>_Descending_4 0.440 ns 0.347 ns BM_MakeHeap_pair<uint32, uint32>_Descending_16 0.529 ns 0.520 ns BM_MakeHeap_pair<uint32, uint32>_Descending_64 0.540 ns 0.527 ns BM_MakeHeap_pair<uint32, uint32>_Descending_256 0.637 ns 0.583 ns BM_MakeHeap_pair<uint32, uint32>_Descending_1024 0.552 ns 0.513 ns BM_MakeHeap_pair<uint32, uint32>_Descending_16384 0.522 ns 0.488 ns BM_MakeHeap_pair<uint32, uint32>_Descending_262144 0.515 ns 0.492 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_1 0.299 ns 0.377 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_4 0.787 ns 0.474 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_16 1.07 ns 0.921 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_64 1.20 ns 1.15 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_256 1.30 ns 1.27 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_1024 1.30 ns 1.31 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_16384 1.29 ns 1.28 ns BM_MakeHeap_pair<uint32, uint32>_SingleElement_262144 1.37 ns 1.38 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_1 0.293 ns 0.385 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_4 0.677 ns 0.438 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_16 1.04 ns 1.00 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_64 1.20 ns 1.27 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_256 1.40 ns 1.43 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_1024 1.36 ns 1.43 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_16384 1.27 ns 1.31 ns BM_MakeHeap_pair<uint32, uint32>_PipeOrgan_262144 1.37 ns 1.41 ns BM_MakeHeap_pair<uint32, uint32>_Heap_1 0.292 ns 0.378 ns BM_MakeHeap_pair<uint32, uint32>_Heap_4 0.440 ns 0.380 ns BM_MakeHeap_pair<uint32, uint32>_Heap_16 0.560 ns 0.606 ns BM_MakeHeap_pair<uint32, uint32>_Heap_64 0.588 ns 0.573 ns BM_MakeHeap_pair<uint32, uint32>_Heap_256 0.632 ns 0.607 ns BM_MakeHeap_pair<uint32, uint32>_Heap_1024 0.598 ns 0.580 ns BM_MakeHeap_pair<uint32, uint32>_Heap_16384 0.576 ns 0.563 ns BM_MakeHeap_pair<uint32, uint32>_Heap_262144 0.572 ns 0.561 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_1 0.304 ns 0.379 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_4 0.823 ns 0.430 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_16 1.08 ns 1.03 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_64 1.18 ns 1.23 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_256 1.39 ns 1.43 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_1024 1.36 ns 1.42 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_16384 1.28 ns 1.32 ns BM_MakeHeap_pair<uint32, uint32>_QuickSortAdversary_262144 1.34 ns 1.37 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_1 0.276 ns 0.511 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_4 4.25 ns 1.96 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_16 4.84 ns 3.77 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_64 5.53 ns 4.93 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_256 5.30 ns 5.06 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_1024 5.29 ns 5.02 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_16384 5.53 ns 5.31 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Random_262144 5.49 ns 5.29 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_1 0.275 ns 0.443 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_4 1.22 ns 0.764 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_16 1.39 ns 1.49 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_64 1.66 ns 1.76 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_256 1.85 ns 1.99 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_1024 1.90 ns 2.02 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_16384 2.15 ns 2.27 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Ascending_262144 2.25 ns 2.37 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_1 0.274 ns 0.445 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_4 0.939 ns 0.520 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_16 1.02 ns 0.811 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_64 1.01 ns 0.941 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_256 1.03 ns 1.01 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_1024 0.969 ns 0.947 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_16384 0.882 ns 0.876 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Descending_262144 0.893 ns 0.871 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_1 0.276 ns 0.443 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_4 1.34 ns 0.870 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_16 1.60 ns 1.59 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_64 1.91 ns 2.00 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_256 1.91 ns 2.08 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_1024 1.91 ns 2.10 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_16384 2.13 ns 2.35 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_SingleElement_262144 2.25 ns 2.48 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_1 0.275 ns 0.446 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_4 1.07 ns 0.671 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_16 1.36 ns 1.44 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_64 1.70 ns 1.80 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_256 1.88 ns 2.05 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_1024 1.92 ns 2.06 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_16384 2.11 ns 2.26 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_PipeOrgan_262144 2.18 ns 2.34 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_1 0.274 ns 0.441 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_4 0.938 ns 0.587 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_16 1.01 ns 0.873 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_64 1.08 ns 1.00 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_256 1.21 ns 1.18 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_1024 1.37 ns 1.29 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_16384 1.31 ns 1.26 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_Heap_262144 1.29 ns 1.25 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_1 0.275 ns 0.447 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_4 1.22 ns 0.764 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_16 1.35 ns 1.46 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_64 1.63 ns 1.73 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_256 1.83 ns 1.87 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_1024 1.81 ns 1.94 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_16384 2.06 ns 2.19 ns BM_MakeHeap_tuple<uint32, uint64, uint32>_QuickSortAdversary_262144 2.14 ns 2.31 ns BM_MakeHeap_string_Random_1 0.289 ns 0.446 ns BM_MakeHeap_string_Random_4 7.43 ns 4.84 ns BM_MakeHeap_string_Random_16 9.73 ns 8.92 ns BM_MakeHeap_string_Random_64 11.5 ns 11.5 ns BM_MakeHeap_string_Random_256 12.6 ns 12.4 ns BM_MakeHeap_string_Random_1024 13.2 ns 13.2 ns BM_MakeHeap_string_Random_16384 15.4 ns 15.4 ns BM_MakeHeap_string_Random_262144 21.4 ns 21.5 ns BM_MakeHeap_string_Ascending_1 0.287 ns 0.447 ns BM_MakeHeap_string_Ascending_4 3.22 ns 2.44 ns BM_MakeHeap_string_Ascending_16 3.77 ns 3.62 ns BM_MakeHeap_string_Ascending_64 4.84 ns 5.17 ns BM_MakeHeap_string_Ascending_256 5.79 ns 6.04 ns BM_MakeHeap_string_Ascending_1024 5.93 ns 6.60 ns BM_MakeHeap_string_Ascending_16384 6.84 ns 7.25 ns BM_MakeHeap_string_Ascending_262144 13.5 ns 14.3 ns BM_MakeHeap_string_Descending_1 0.293 ns 0.447 ns BM_MakeHeap_string_Descending_4 2.61 ns 1.83 ns BM_MakeHeap_string_Descending_16 2.64 ns 2.60 ns BM_MakeHeap_string_Descending_64 2.75 ns 2.74 ns BM_MakeHeap_string_Descending_256 3.78 ns 3.57 ns BM_MakeHeap_string_Descending_1024 3.20 ns 3.51 ns BM_MakeHeap_string_Descending_16384 3.57 ns 3.85 ns BM_MakeHeap_string_Descending_262144 6.27 ns 6.39 ns BM_MakeHeap_string_SingleElement_1 0.291 ns 0.448 ns BM_MakeHeap_string_SingleElement_4 3.88 ns 2.71 ns BM_MakeHeap_string_SingleElement_16 5.08 ns 4.96 ns BM_MakeHeap_string_SingleElement_64 6.14 ns 6.29 ns BM_MakeHeap_string_SingleElement_256 6.13 ns 6.46 ns BM_MakeHeap_string_SingleElement_1024 5.98 ns 6.60 ns BM_MakeHeap_string_SingleElement_16384 5.88 ns 6.39 ns BM_MakeHeap_string_SingleElement_262144 9.95 ns 10.2 ns BM_MakeHeap_string_PipeOrgan_1 0.292 ns 0.447 ns BM_MakeHeap_string_PipeOrgan_4 2.97 ns 2.51 ns BM_MakeHeap_string_PipeOrgan_16 3.76 ns 3.91 ns BM_MakeHeap_string_PipeOrgan_64 4.89 ns 5.20 ns BM_MakeHeap_string_PipeOrgan_256 5.77 ns 6.09 ns BM_MakeHeap_string_PipeOrgan_1024 6.14 ns 6.40 ns BM_MakeHeap_string_PipeOrgan_16384 6.83 ns 7.32 ns BM_MakeHeap_string_PipeOrgan_262144 13.8 ns 14.6 ns BM_MakeHeap_string_Heap_1 0.288 ns 0.515 ns BM_MakeHeap_string_Heap_4 3.62 ns 4.20 ns BM_MakeHeap_string_Heap_16 5.36 ns 5.23 ns BM_MakeHeap_string_Heap_64 5.79 ns 5.38 ns BM_MakeHeap_string_Heap_256 5.70 ns 5.40 ns BM_MakeHeap_string_Heap_1024 5.78 ns 5.37 ns BM_MakeHeap_string_Heap_16384 6.09 ns 5.67 ns BM_MakeHeap_string_Heap_262144 6.37 ns 5.96 ns BM_MakeHeap_string_QuickSortAdversary_1 0.282 ns 0.448 ns BM_MakeHeap_string_QuickSortAdversary_4 7.45 ns 5.60 ns BM_MakeHeap_string_QuickSortAdversary_16 9.76 ns 8.85 ns BM_MakeHeap_string_QuickSortAdversary_64 11.5 ns 11.2 ns BM_MakeHeap_string_QuickSortAdversary_256 12.0 ns 11.8 ns BM_MakeHeap_string_QuickSortAdversary_1024 12.2 ns 12.0 ns BM_MakeHeap_string_QuickSortAdversary_16384 13.7 ns 13.6 ns BM_MakeHeap_string_QuickSortAdversary_262144 14.1 ns 14.8 ns BM_MakeHeap_float_Random_1 0.287 ns 0.287 ns BM_MakeHeap_float_Random_4 2.29 ns 2.60 ns BM_MakeHeap_float_Random_16 4.00 ns 2.48 ns BM_MakeHeap_float_Random_64 4.41 ns 1.92 ns BM_MakeHeap_float_Random_256 4.73 ns 2.05 ns BM_MakeHeap_float_Random_1024 4.90 ns 2.27 ns BM_MakeHeap_float_Random_16384 4.42 ns 2.27 ns BM_MakeHeap_float_Random_262144 4.72 ns 1.39 ns BM_MakeHeap_float_Ascending_1 0.291 ns 0.293 ns BM_MakeHeap_float_Ascending_4 0.633 ns 0.428 ns BM_MakeHeap_float_Ascending_16 0.638 ns 0.874 ns BM_MakeHeap_float_Ascending_64 0.614 ns 0.698 ns BM_MakeHeap_float_Ascending_256 0.663 ns 0.713 ns BM_MakeHeap_float_Ascending_1024 0.660 ns 0.761 ns BM_MakeHeap_float_Ascending_16384 0.628 ns 0.725 ns BM_MakeHeap_float_Ascending_262144 0.629 ns 0.814 ns BM_MakeHeap_float_Descending_1 0.290 ns 0.290 ns BM_MakeHeap_float_Descending_4 0.421 ns 0.316 ns BM_MakeHeap_float_Descending_16 0.302 ns 0.225 ns BM_MakeHeap_float_Descending_64 0.293 ns 0.212 ns BM_MakeHeap_float_Descending_256 0.314 ns 0.246 ns BM_MakeHeap_float_Descending_1024 0.300 ns 0.231 ns BM_MakeHeap_float_Descending_16384 0.308 ns 0.205 ns BM_MakeHeap_float_Descending_262144 0.309 ns 0.203 ns BM_MakeHeap_float_SingleElement_1 0.289 ns 0.292 ns BM_MakeHeap_float_SingleElement_4 0.569 ns 0.347 ns BM_MakeHeap_float_SingleElement_16 0.538 ns 0.825 ns BM_MakeHeap_float_SingleElement_64 0.585 ns 0.727 ns BM_MakeHeap_float_SingleElement_256 0.603 ns 0.708 ns BM_MakeHeap_float_SingleElement_1024 0.618 ns 0.760 ns BM_MakeHeap_float_SingleElement_16384 0.599 ns 0.726 ns BM_MakeHeap_float_SingleElement_262144 0.723 ns 0.820 ns BM_MakeHeap_float_PipeOrgan_1 0.289 ns 0.291 ns BM_MakeHeap_float_PipeOrgan_4 0.457 ns 0.420 ns BM_MakeHeap_float_PipeOrgan_16 0.670 ns 1.32 ns BM_MakeHeap_float_PipeOrgan_64 0.764 ns 0.889 ns BM_MakeHeap_float_PipeOrgan_256 0.793 ns 0.757 ns BM_MakeHeap_float_PipeOrgan_1024 0.755 ns 0.764 ns BM_MakeHeap_float_PipeOrgan_16384 0.723 ns 0.723 ns BM_MakeHeap_float_PipeOrgan_262144 0.654 ns 0.817 ns BM_MakeHeap_float_Heap_1 0.291 ns 0.289 ns BM_MakeHeap_float_Heap_4 0.388 ns 0.316 ns BM_MakeHeap_float_Heap_16 0.317 ns 0.225 ns BM_MakeHeap_float_Heap_64 0.353 ns 0.213 ns BM_MakeHeap_float_Heap_256 0.361 ns 0.246 ns BM_MakeHeap_float_Heap_1024 0.381 ns 0.233 ns BM_MakeHeap_float_Heap_16384 0.390 ns 0.205 ns BM_MakeHeap_float_Heap_262144 0.379 ns 0.202 ns BM_MakeHeap_float_QuickSortAdversary_1 0.295 ns 0.289 ns BM_MakeHeap_float_QuickSortAdversary_4 0.640 ns 0.422 ns BM_MakeHeap_float_QuickSortAdversary_16 0.658 ns 0.871 ns BM_MakeHeap_float_QuickSortAdversary_64 0.574 ns 0.659 ns BM_MakeHeap_float_QuickSortAdversary_256 0.631 ns 0.550 ns BM_MakeHeap_float_QuickSortAdversary_1024 0.617 ns 0.552 ns BM_MakeHeap_float_QuickSortAdversary_16384 0.424 ns 0.283 ns BM_MakeHeap_float_QuickSortAdversary_262144 0.386 ns 0.219 ns Fixes #120752 | 10 个月前 | |
[libc++][modules] Fix missing and incorrect includes (#108850) This patch adds a large number of missing includes in the libc++ headers and the test suite. Those were found as part of the effort to move towards a mostly monolithic top-level std module. | 1 年前 | |
[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 | 2 年前 | |
[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 | 2 年前 | |
[libc++][NFC] Merge is{,_nothrow,_trivially}{,_copy,_move,_default}{_assignable,_constructible} (#85308) These headers have become very small by using compiler builtins, often containing only two declarations. This merges these headers, since there doesn't seem to be much of a benefit keeping them separate. Specifically, is_{,_nothrow,_trivially}{assignable,constructible} are kept and the copy, move and default versions of these type traits are moved in to the respective headers. | 2 年前 | |
[libc++] Fix missing and incorrect push/pop macros (#79204) We recently noticed that the unwrap_iter.h file was pushing macros, but it was pushing them again instead of popping them at the end of the file. This led to libc++ basically swallowing any custom definition of these macros in user code: #define min HELLO #include <algorithm> // min is not HELLO anymore, it's not defined While investigating this issue, I noticed that our push/pop pragmas were actually entirely wrong too. Indeed, instead of pushing macros like move, we'd push move(int, int) in the pragma, which is not a valid macro name. As a result, we would not actually push macros like move -- instead we'd simply undefine them. This led to the following code not working: #define move HELLO #include <algorithm> // move is not HELLO anymore Fixing the pragma push/pop incantations led to a cascade of issues because we use identifiers like move in a large number of places, and all of these headers would now need to do the push/pop dance. This patch fixes all these issues. First, it adds a check that we don't swallow important names like min, max, move or refresh as explained above. This is done by augmenting the existing system_reserved_names.gen.py test to also check that the macros are what we expect after including each header. Second, it fixes the push/pop pragmas to work properly and adds missing pragmas to all the files I could detect a failure in via the newly added test. rdar://121365472 | 2 年前 | |
[libc++] Make the naming of the iterator_traits aliases consistent (#161661) This renames all the iterator_traits alises to be __iterator_<type-name>. e.g iterator_traits<T>::value_type will be __iterator_value_type<T>. | 9 个月前 | |
[libc++][NFC] Merge is{,_nothrow,_trivially}{,_copy,_move,_default}{_assignable,_constructible} (#85308) These headers have become very small by using compiler builtins, often containing only two declarations. This merges these headers, since there doesn't seem to be much of a benefit keeping them separate. Specifically, is_{,_nothrow,_trivially}{assignable,constructible} are kept and the copy, move and default versions of these type traits are moved in to the respective headers. | 2 年前 | |
[libc++] Make the naming of the iterator_traits aliases consistent (#161661) This renames all the iterator_traits alises to be __iterator_<type-name>. e.g iterator_traits<T>::value_type will be __iterator_value_type<T>. | 9 个月前 | |
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove _AlgPolicy from std::copy and algorithms using std::copy (#115887) std::copy doesn't use the _AlgPolicy for anything other than calling itself with it, so we can just remove the argument. This also removes the need in a few other algorithms which had an _AlgPolicy argument only to call copy. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
| 1 年前 | ||
[libc++] Remove _AlgPolicy from std::copy and algorithms using std::copy (#115887) std::copy doesn't use the _AlgPolicy for anything other than calling itself with it, so we can just remove the argument. This also removes the need in a few other algorithms which had an _AlgPolicy argument only to call copy. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
| 1 年前 | ||
[libc++][modules] Fix missing and incorrect includes (#108850) This patch adds a large number of missing includes in the libc++ headers and the test suite. Those were found as part of the effort to move towards a mostly monolithic top-level std module. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[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> | 9 个月前 | |
| 1 年前 | ||
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++][modules] Fix missing and incorrect includes (#108850) This patch adds a large number of missing includes in the libc++ headers and the test suite. Those were found as part of the effort to move towards a mostly monolithic top-level std module. | 1 年前 | |
[libc++][NFC] Rename fold.h to ranges_fold.h (#109696) This follows the pattern we use consistently for ranges algorithms. This is a re-application of 24bc3244d4e which had been reverted in f11abac65 due to unrelated failures. | 1 年前 | |
[libc++] Optimize ranges::{for_each, for_each_n} for segmented iterators (#132896) Previously, the segmented iterator optimization was limited to std::{for_each, for_each_n}. This patch extends the optimization to std::ranges::for_each and std::ranges::for_each_n, ensuring consistent optimizations across these algorithms. This patch first generalizes the std algorithms by introducing a Projection parameter, which is set to __identity for the std algorithms. Then we let the ranges algorithms to directly call their std counterparts with a general __proj argument. Benchmarks demonstrate performance improvements of up to 21.4x for std::deque::iterator and 22.3x for join_view of vector<vector<char>>. Addresses a subtask of #102817. | 1 年前 | |
[libc++] Optimize ranges::{for_each, for_each_n} for segmented iterators (#132896) Previously, the segmented iterator optimization was limited to std::{for_each, for_each_n}. This patch extends the optimization to std::ranges::for_each and std::ranges::for_each_n, ensuring consistent optimizations across these algorithms. This patch first generalizes the std algorithms by introducing a Projection parameter, which is set to __identity for the std algorithms. Then we let the ranges algorithms to directly call their std counterparts with a general __proj argument. Benchmarks demonstrate performance improvements of up to 21.4x for std::deque::iterator and 22.3x for join_view of vector<vector<char>>. Addresses a subtask of #102817. | 1 年前 | |
[libc++][modules] Fix missing and incorrect includes (#108850) This patch adds a large number of missing includes in the libc++ headers and the test suite. Those were found as part of the effort to move towards a mostly monolithic top-level std module. | 1 年前 | |
[libcxx] Optimize rng::generate_n for segmented iterators (#165280) Part of #102817. This patch optimizes rng::generate_n for segmented iterators by forwarding the implementation directly to std::generate_n. - before rng::generate_n(deque<int>)/32 21.7 ns 22.0 ns 32000000 rng::generate_n(deque<int>)/50 30.8 ns 30.7 ns 22400000 rng::generate_n(deque<int>)/1024 492 ns 488 ns 1120000 rng::generate_n(deque<int>)/8192 3938 ns 3924 ns 179200 - after rng::generate_n(deque<int>)/32 11.0 ns 11.0 ns 64000000 rng::generate_n(deque<int>)/50 16.2 ns 16.1 ns 40727273 rng::generate_n(deque<int>)/1024 292 ns 286 ns 2240000 rng::generate_n(deque<int>)/8192 2291 ns 2302 ns 298667 | 9 个月前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Implement part of P2562R1: constexpr ranges::inplace_merge (#131947) Drive-by changes: - Consistently mark std::__inplace_merge::__inplace_merge_impl _LIBCPP_CONSTEXPR_SINCE_CXX26. - This function template is only called by other functions that becomes constexpr since C++26, and it itself calls std::__inplace_merge that is constexpr since C++26. - Unblock related test coverage in constant evaluation for stable_partition, ranges::stable_sort, std::stable_sort, std::stable_partition, and std::inplace_merge. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Qualify calls to nullary functions like __throw_foo (#122465) This is technically not necessary in most cases to prevent issues with ADL, but let's be consistent. This allows us to remove the libcpp-qualify-declval clang-tidy check, which is now enforced by the robust-against-adl clang-tidy check. | 1 年前 | |
[libc++] Optimize lexicographical_compare (#65279) If the comparison operation is equivalent to < and that is a total order, we know that we can use equality comparison on that type instead to extract some information. Furthermore, if equality comparison on that type is trivial, the user can't observe that we're calling it. So instead of using the user-provided total order, we use std::mismatch, which uses equality comparison (and is vertorized). Additionally, if the type is trivially lexicographically comparable, we can go one step further and use std::memcmp directly instead of calling std::mismatch. Benchmarks: ------------------------------------------------------------------------------------- Benchmark old new ------------------------------------------------------------------------------------- bm_lexicographical_compare<unsigned char>/1 1.17 ns 2.34 ns bm_lexicographical_compare<unsigned char>/2 1.64 ns 2.57 ns bm_lexicographical_compare<unsigned char>/3 2.23 ns 2.58 ns bm_lexicographical_compare<unsigned char>/4 2.82 ns 2.57 ns bm_lexicographical_compare<unsigned char>/5 3.34 ns 2.11 ns bm_lexicographical_compare<unsigned char>/6 3.94 ns 2.21 ns bm_lexicographical_compare<unsigned char>/7 4.56 ns 2.11 ns bm_lexicographical_compare<unsigned char>/8 5.25 ns 2.11 ns bm_lexicographical_compare<unsigned char>/16 9.88 ns 2.11 ns bm_lexicographical_compare<unsigned char>/64 38.9 ns 2.36 ns bm_lexicographical_compare<unsigned char>/512 317 ns 6.54 ns bm_lexicographical_compare<unsigned char>/4096 2517 ns 41.4 ns bm_lexicographical_compare<unsigned char>/32768 20052 ns 488 ns bm_lexicographical_compare<unsigned char>/262144 159579 ns 4409 ns bm_lexicographical_compare<unsigned char>/1048576 640456 ns 20342 ns bm_lexicographical_compare<signed char>/1 1.18 ns 2.37 ns bm_lexicographical_compare<signed char>/2 1.65 ns 2.60 ns bm_lexicographical_compare<signed char>/3 2.23 ns 2.83 ns bm_lexicographical_compare<signed char>/4 2.81 ns 3.06 ns bm_lexicographical_compare<signed char>/5 3.35 ns 3.30 ns bm_lexicographical_compare<signed char>/6 3.90 ns 3.99 ns bm_lexicographical_compare<signed char>/7 4.56 ns 3.78 ns bm_lexicographical_compare<signed char>/8 5.20 ns 4.02 ns bm_lexicographical_compare<signed char>/16 9.80 ns 6.21 ns bm_lexicographical_compare<signed char>/64 39.0 ns 3.16 ns bm_lexicographical_compare<signed char>/512 318 ns 7.58 ns bm_lexicographical_compare<signed char>/4096 2514 ns 47.4 ns bm_lexicographical_compare<signed char>/32768 20096 ns 504 ns bm_lexicographical_compare<signed char>/262144 156617 ns 4146 ns bm_lexicographical_compare<signed char>/1048576 624265 ns 19810 ns bm_lexicographical_compare<int>/1 1.15 ns 2.12 ns bm_lexicographical_compare<int>/2 1.60 ns 2.36 ns bm_lexicographical_compare<int>/3 2.21 ns 2.59 ns bm_lexicographical_compare<int>/4 2.74 ns 2.83 ns bm_lexicographical_compare<int>/5 3.26 ns 3.06 ns bm_lexicographical_compare<int>/6 3.81 ns 4.53 ns bm_lexicographical_compare<int>/7 4.41 ns 4.72 ns bm_lexicographical_compare<int>/8 5.08 ns 2.36 ns bm_lexicographical_compare<int>/16 9.54 ns 3.08 ns bm_lexicographical_compare<int>/64 37.8 ns 4.71 ns bm_lexicographical_compare<int>/512 309 ns 24.6 ns bm_lexicographical_compare<int>/4096 2422 ns 204 ns bm_lexicographical_compare<int>/32768 19362 ns 1947 ns bm_lexicographical_compare<int>/262144 155727 ns 19793 ns bm_lexicographical_compare<int>/1048576 623614 ns 80180 ns bm_ranges_lexicographical_compare<unsigned char>/1 1.07 ns 2.35 ns bm_ranges_lexicographical_compare<unsigned char>/2 1.72 ns 2.13 ns bm_ranges_lexicographical_compare<unsigned char>/3 2.46 ns 2.12 ns bm_ranges_lexicographical_compare<unsigned char>/4 3.17 ns 2.12 ns bm_ranges_lexicographical_compare<unsigned char>/5 3.86 ns 2.12 ns bm_ranges_lexicographical_compare<unsigned char>/6 4.55 ns 2.12 ns bm_ranges_lexicographical_compare<unsigned char>/7 5.25 ns 2.12 ns bm_ranges_lexicographical_compare<unsigned char>/8 5.95 ns 2.13 ns bm_ranges_lexicographical_compare<unsigned char>/16 11.7 ns 2.13 ns bm_ranges_lexicographical_compare<unsigned char>/64 45.5 ns 2.36 ns bm_ranges_lexicographical_compare<unsigned char>/512 366 ns 6.35 ns bm_ranges_lexicographical_compare<unsigned char>/4096 2886 ns 40.9 ns bm_ranges_lexicographical_compare<unsigned char>/32768 23054 ns 489 ns bm_ranges_lexicographical_compare<unsigned char>/262144 185302 ns 4339 ns bm_ranges_lexicographical_compare<unsigned char>/1048576 741576 ns 19430 ns bm_ranges_lexicographical_compare<signed char>/1 1.10 ns 2.12 ns bm_ranges_lexicographical_compare<signed char>/2 1.66 ns 2.35 ns bm_ranges_lexicographical_compare<signed char>/3 2.23 ns 2.58 ns bm_ranges_lexicographical_compare<signed char>/4 2.82 ns 2.82 ns bm_ranges_lexicographical_compare<signed char>/5 3.34 ns 3.06 ns bm_ranges_lexicographical_compare<signed char>/6 3.92 ns 3.99 ns bm_ranges_lexicographical_compare<signed char>/7 4.64 ns 4.10 ns bm_ranges_lexicographical_compare<signed char>/8 5.21 ns 4.61 ns bm_ranges_lexicographical_compare<signed char>/16 9.79 ns 7.42 ns bm_ranges_lexicographical_compare<signed char>/64 38.9 ns 2.93 ns bm_ranges_lexicographical_compare<signed char>/512 317 ns 7.31 ns bm_ranges_lexicographical_compare<signed char>/4096 2500 ns 47.5 ns bm_ranges_lexicographical_compare<signed char>/32768 19940 ns 496 ns bm_ranges_lexicographical_compare<signed char>/262144 159166 ns 4393 ns bm_ranges_lexicographical_compare<signed char>/1048576 638206 ns 19786 ns bm_ranges_lexicographical_compare<int>/1 1.10 ns 2.12 ns bm_ranges_lexicographical_compare<int>/2 1.64 ns 3.04 ns bm_ranges_lexicographical_compare<int>/3 2.23 ns 2.58 ns bm_ranges_lexicographical_compare<int>/4 2.81 ns 2.81 ns bm_ranges_lexicographical_compare<int>/5 3.35 ns 3.05 ns bm_ranges_lexicographical_compare<int>/6 3.94 ns 4.60 ns bm_ranges_lexicographical_compare<int>/7 4.60 ns 4.81 ns bm_ranges_lexicographical_compare<int>/8 5.19 ns 2.35 ns bm_ranges_lexicographical_compare<int>/16 9.85 ns 2.87 ns bm_ranges_lexicographical_compare<int>/64 38.9 ns 4.70 ns bm_ranges_lexicographical_compare<int>/512 318 ns 24.5 ns bm_ranges_lexicographical_compare<int>/4096 2494 ns 202 ns bm_ranges_lexicographical_compare<int>/32768 20000 ns 1939 ns bm_ranges_lexicographical_compare<int>/262144 160433 ns 19730 ns bm_ranges_lexicographical_compare<int>/1048576 642636 ns 80760 ns | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Refactor ranges::{min, max, min_element, max_element} to use std::__min_element (#132418) Previously, ranges::min_element delegated to ranges::__min_element_impl, which duplicated the definition of std::__min_element. This patch updates ranges::min_element to directly call std::__min_element, which allows removing the redundant code in ranges::__min_element_impl. Upon removal of ranges::__min_element_impl, the other ranges algorithms ranges::{min,max,max_element}, which previously delegated to ranges::__min_element_impl, have been updated to call std::__min_element instead. This refactoring unifies the implementation across these algorithms, ensuring that future optimizations or maintenance work only need to be applied in one place. | 1 年前 | |
[libc++] Refactor ranges::{min, max, min_element, max_element} to use std::__min_element (#132418) Previously, ranges::min_element delegated to ranges::__min_element_impl, which duplicated the definition of std::__min_element. This patch updates ranges::min_element to directly call std::__min_element, which allows removing the redundant code in ranges::__min_element_impl. Upon removal of ranges::__min_element_impl, the other ranges algorithms ranges::{min,max,max_element}, which previously delegated to ranges::__min_element_impl, have been updated to call std::__min_element instead. This refactoring unifies the implementation across these algorithms, ensuring that future optimizations or maintenance work only need to be applied in one place. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Refactor ranges::{min, max, min_element, max_element} to use std::__min_element (#132418) Previously, ranges::min_element delegated to ranges::__min_element_impl, which duplicated the definition of std::__min_element. This patch updates ranges::min_element to directly call std::__min_element, which allows removing the redundant code in ranges::__min_element_impl. Upon removal of ranges::__min_element_impl, the other ranges algorithms ranges::{min,max,max_element}, which previously delegated to ranges::__min_element_impl, have been updated to call std::__min_element instead. This refactoring unifies the implementation across these algorithms, ensuring that future optimizations or maintenance work only need to be applied in one place. | 1 年前 | |
[libc++] Refactor ranges::{min, max, min_element, max_element} to use std::__min_element (#132418) Previously, ranges::min_element delegated to ranges::__min_element_impl, which duplicated the definition of std::__min_element. This patch updates ranges::min_element to directly call std::__min_element, which allows removing the redundant code in ranges::__min_element_impl. Upon removal of ranges::__min_element_impl, the other ranges algorithms ranges::{min,max,max_element}, which previously delegated to ranges::__min_element_impl, have been updated to call std::__min_element instead. This refactoring unifies the implementation across these algorithms, ensuring that future optimizations or maintenance work only need to be applied in one place. | 1 年前 | |
Reapply "[libc++] Simplify the implementation of std::sort a bit (#104902)" (#114023) This reverts commit ef44e4659878f2. The patch was originally reverted because it was deemed to introduce a performance regression for small inputs, however it also fixed a previous performance regression for larger inputs. So overall, this patch is desirable. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++][modules] Fix missing and incorrect includes (#108850) This patch adds a large number of missing includes in the libc++ headers and the test suite. Those were found as part of the effort to move towards a mostly monolithic top-level std module. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove _AlgPolicy from std::copy and algorithms using std::copy (#115887) std::copy doesn't use the _AlgPolicy for anything other than calling itself with it, so we can just remove the argument. This also removes the need in a few other algorithms which had an _AlgPolicy argument only to call copy. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove _AlgPolicy from std::copy and algorithms using std::copy (#115887) std::copy doesn't use the _AlgPolicy for anything other than calling itself with it, so we can just remove the argument. This also removes the need in a few other algorithms which had an _AlgPolicy argument only to call copy. | 1 年前 | |
[libc++] Remove _AlgPolicy from std::copy and algorithms using std::copy (#115887) std::copy doesn't use the _AlgPolicy for anything other than calling itself with it, so we can just remove the argument. This also removes the need in a few other algorithms which had an _AlgPolicy argument only to call copy. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Implement part of P2562R1: constexpr ranges::stable_partition (#129839) | 1 年前 | |
[libc++] Implement part of P2562R1: constexpr ranges::stable_sort (#128860) Drive-by: Enables test coverage for ranges::stable_sort with proxy iterators, and changes "constexpr in" to "constexpr since" in comments in <algorithm>. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++] Put _LIBCPP_NODEBUG on all internal aliases (#118710) This significantly reduces the amount of debug information generated for codebases using libc++, without hurting the debugging experience. | 1 年前 | |
[libc++] Remove dedicated namespaces for ranges functions (#76543) We originally put implementation-detail function objects into individual namespaces for std::ranges without a good reason for doing so. This practice was continued, presumably because there was prior art. Since there's no reason to keep these namespaces, this commit removes them, which will slightly impact binary size. This commit does not apply to CPOs, some of which need additional work. | 1 年前 | |
[libc++][NFC] Use [[__nodiscard__]] unconditionally (#80454) __has_cpp_attribute(__nodiscard__) is always true now, so we might as well replace _LIBCPP_NODISCARD. It's one less macro that can result in bad diagnostics. | 1 年前 | |
[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 | 2 年前 | |
[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 | 2 年前 | |
[libc++][NFC] Use [[__nodiscard__]] unconditionally (#80454) __has_cpp_attribute(__nodiscard__) is always true now, so we might as well replace _LIBCPP_NODISCARD. It's one less macro that can result in bad diagnostics. | 1 年前 | |
[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 | 2 年前 | |
[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 | 2 年前 | |
[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 | 2 年前 | |
[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 | 2 年前 | |
[libc++] Fix missing and incorrect push/pop macros (#79204) We recently noticed that the unwrap_iter.h file was pushing macros, but it was pushing them again instead of popping them at the end of the file. This led to libc++ basically swallowing any custom definition of these macros in user code: #define min HELLO #include <algorithm> // min is not HELLO anymore, it's not defined While investigating this issue, I noticed that our push/pop pragmas were actually entirely wrong too. Indeed, instead of pushing macros like move, we'd push move(int, int) in the pragma, which is not a valid macro name. As a result, we would not actually push macros like move -- instead we'd simply undefine them. This led to the following code not working: #define move HELLO #include <algorithm> // move is not HELLO anymore Fixing the pragma push/pop incantations led to a cascade of issues because we use identifiers like move in a large number of places, and all of these headers would now need to do the push/pop dance. This patch fixes all these issues. First, it adds a check that we don't swallow important names like min, max, move or refresh as explained above. This is done by augmenting the existing system_reserved_names.gen.py test to also check that the macros are what we expect after including each header. Second, it fixes the push/pop pragmas to work properly and adds missing pragmas to all the files I could detect a failure in via the newly added test. rdar://121365472 | 2 年前 | |
[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 | 2 年前 | |
| 1 年前 | ||
[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 | 2 年前 | |
[libc++][hardening] Categorize more 'valid-element-access' checks. (#71620) | 2 年前 | |
[libc++][modules] Fix missing and incorrect includes (#108850) This patch adds a large number of missing includes in the libc++ headers and the test suite. Those were found as part of the effort to move towards a mostly monolithic top-level std module. | 1 年前 | |
[libc++][modules] Fix missing and incorrect includes (#108850) This patch adds a large number of missing includes in the libc++ headers and the test suite. Those were found as part of the effort to move towards a mostly monolithic top-level std module. | 1 年前 | |
[libc++] Remove _AlgPolicy from std::copy and algorithms using std::copy (#115887) std::copy doesn't use the _AlgPolicy for anything other than calling itself with it, so we can just remove the argument. This also removes the need in a few other algorithms which had an _AlgPolicy argument only to call copy. | 1 年前 | |
[libc++][modules] Fix missing and incorrect includes (#108850) This patch adds a large number of missing includes in the libc++ headers and the test suite. Those were found as part of the effort to move towards a mostly monolithic top-level std module. | 1 年前 | |
[libc++] Remove _AlgPolicy from std::copy and algorithms using std::copy (#115887) std::copy doesn't use the _AlgPolicy for anything other than calling itself with it, so we can just remove the argument. This also removes the need in a few other algorithms which had an _AlgPolicy argument only to call copy. | 1 年前 | |
[libc++] Remove _AlgPolicy from std::copy and algorithms using std::copy (#115887) std::copy doesn't use the _AlgPolicy for anything other than calling itself with it, so we can just remove the argument. This also removes the need in a few other algorithms which had an _AlgPolicy argument only to call copy. | 1 年前 | |
[libc++] Fix missing and incorrect push/pop macros (#79204) We recently noticed that the unwrap_iter.h file was pushing macros, but it was pushing them again instead of popping them at the end of the file. This led to libc++ basically swallowing any custom definition of these macros in user code: #define min HELLO #include <algorithm> // min is not HELLO anymore, it's not defined While investigating this issue, I noticed that our push/pop pragmas were actually entirely wrong too. Indeed, instead of pushing macros like move, we'd push move(int, int) in the pragma, which is not a valid macro name. As a result, we would not actually push macros like move -- instead we'd simply undefine them. This led to the following code not working: #define move HELLO #include <algorithm> // move is not HELLO anymore Fixing the pragma push/pop incantations led to a cascade of issues because we use identifiers like move in a large number of places, and all of these headers would now need to do the push/pop dance. This patch fixes all these issues. First, it adds a check that we don't swallow important names like min, max, move or refresh as explained above. This is done by augmenting the existing system_reserved_names.gen.py test to also check that the macros are what we expect after including each header. Second, it fixes the push/pop pragmas to work properly and adds missing pragmas to all the files I could detect a failure in via the newly added test. rdar://121365472 | 2 年前 | |
[libc++] Fix missing and incorrect push/pop macros (#79204) We recently noticed that the unwrap_iter.h file was pushing macros, but it was pushing them again instead of popping them at the end of the file. This led to libc++ basically swallowing any custom definition of these macros in user code: #define min HELLO #include <algorithm> // min is not HELLO anymore, it's not defined While investigating this issue, I noticed that our push/pop pragmas were actually entirely wrong too. Indeed, instead of pushing macros like move, we'd push move(int, int) in the pragma, which is not a valid macro name. As a result, we would not actually push macros like move -- instead we'd simply undefine them. This led to the following code not working: #define move HELLO #include <algorithm> // move is not HELLO anymore Fixing the pragma push/pop incantations led to a cascade of issues because we use identifiers like move in a large number of places, and all of these headers would now need to do the push/pop dance. This patch fixes all these issues. First, it adds a check that we don't swallow important names like min, max, move or refresh as explained above. This is done by augmenting the existing system_reserved_names.gen.py test to also check that the macros are what we expect after including each header. Second, it fixes the push/pop pragmas to work properly and adds missing pragmas to all the files I could detect a failure in via the newly added test. rdar://121365472 | 2 年前 | |
Revert "[libc++] Introduce ABI sensitive areas to avoid requiring _LIBCPP_HIDE_FROM_ABI everywhere (#131156)" (#141756) This reverts commit c861fe8a71e64f3d2108c58147e7375cd9314521. Unfortunately, this use of hidden visibility attributes causes user-defined specializations of standard-library types to also be marked hidden by default, which is incorrect. See discussion thread on #131156. ...and also reverts the follow-up commits: Revert "[libc++] Add explicit ABI annotations to functions from the block runtime declared in <__functional/function.h> (#140592)" This reverts commit 3e4c9dc299c35155934688184319d391b298fff7. Revert "[libc++] Make ABI annotations explicit for windows-specific code (#140507)" This reverts commit f73287e623a6c2e4a3485832bc3e10860cd26eb5. Revert "[libc++][NFC] Replace a few "namespace std" with the correct macro (#140510)" This reverts commit 1d411f27c769a32cb22ce50b9dc4421e34fd40dd. | 1 年前 | |
[libc++] Make the naming of the iterator_traits aliases consistent (#161661) This renames all the iterator_traits alises to be __iterator_<type-name>. e.g iterator_traits<T>::value_type will be __iterator_value_type<T>. | 9 个月前 | |
[libc++] Optimize num_get integral functions (#121795) --------------------------------------------------- Benchmark old new --------------------------------------------------- BM_num_get<bool> 86.5 ns 32.3 ns BM_num_get<long> 82.1 ns 30.3 ns BM_num_get<long long> 85.2 ns 33.4 ns BM_num_get<unsigned short> 85.3 ns 31.2 ns BM_num_get<unsigned int> 84.2 ns 31.1 ns BM_num_get<unsigned long> 83.6 ns 31.9 ns BM_num_get<unsigned long long> 87.7 ns 31.5 ns BM_num_get<float> 116 ns 114 ns BM_num_get<double> 114 ns 114 ns BM_num_get<long double> 113 ns 114 ns BM_num_get<void*> 151 ns 144 ns This patch applies multiple optimizations: - Stages two and three of do_get are merged and a custom integer parser has been implemented This avoids allocations, removes the need for strto{,u}ll and avoids __stage2_int_loop (avoiding extra writes to memory) - std::find has been replaced with __atoms_offset, which uses vector instructions to look for a character Fixes #158100 Fixes #158102 | 8 个月前 | |
[libc++] Fix broken precondition of __bit_log2 (#155476) In #135303, we started using __bit_log2 instead of __log2i inside std::sort. However, __bit_log2 has a precondition that __log2i didn't have, which is that the input is non-zero. While it technically makes no sense to request the logarithm of 0, __log2i handled that case and returned 0 without issues. After switching to __bit_log2, passing 0 as an input results in an unsigned integer overflow which can trigger -fsanitize=unsigned-integer-overflow. While not technically UB in itself, it's clearly not intended either. To fix this, we add an internal assertion to __bit_log2 which catches the issue in our test suite, and we make sure not to violate __bit_log2's preconditions before we call it from std::sort. | 10 个月前 | |
[libc++][NFC] Merge is{,_nothrow,_trivially}{,_copy,_move,_default}{_assignable,_constructible} (#85308) These headers have become very small by using compiler builtins, often containing only two declarations. This merges these headers, since there doesn't seem to be much of a benefit keeping them separate. Specifically, is_{,_nothrow,_trivially}{assignable,constructible} are kept and the copy, move and default versions of these type traits are moved in to the respective headers. | 2 年前 | |
[libc++] Implement part of P2562R1: constexpr std::stable_partition (#128868) Drive-by changes: - Enables no-memory case for Clang. - Enables robust_re_difference_type.compile.pass.cpp and robust_against_proxy_iterators_lifetime_bugs.pass.cpp test coverage for std::stable_sort in constant evaluation since C++26. The changes were missing in the PR making std::stable_sort constexpr. | 1 年前 | |
[libc++] Make the naming of the iterator_traits aliases consistent (#161661) This renames all the iterator_traits alises to be __iterator_<type-name>. e.g iterator_traits<T>::value_type will be __iterator_value_type<T>. | 9 个月前 | |
[libc++] Optimize ranges::swap_ranges for vector<bool>::iterator (#121150) This PR optimizes the performance of std::ranges::swap_ranges for vector<bool>::iterator, addressing a subtask outlined in issue #64038. The optimizations yield performance improvements of up to **611x** for aligned range swap and **78x** for unaligned range swap comparison. Additionally, comprehensive tests covering up to 4 storage words (256 bytes) with odd and even bit sizes are provided, which validate the proposed optimizations in this patch. | 1 年前 | |
[libc++] Put _LIBCPP_NODEBUG on all internal aliases (#118710) This significantly reduces the amount of debug information generated for codebases using libc++, without hurting the debugging experience. | 1 年前 | |
[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 | 2 年前 | |
[libc++][modules] Fix missing and incorrect includes (#108850) This patch adds a large number of missing includes in the libc++ headers and the test suite. Those were found as part of the effort to move towards a mostly monolithic top-level std module. | 1 年前 | |
| 1 年前 | ||
[libc++] Fix missing and incorrect push/pop macros (#79204) We recently noticed that the unwrap_iter.h file was pushing macros, but it was pushing them again instead of popping them at the end of the file. This led to libc++ basically swallowing any custom definition of these macros in user code: #define min HELLO #include <algorithm> // min is not HELLO anymore, it's not defined While investigating this issue, I noticed that our push/pop pragmas were actually entirely wrong too. Indeed, instead of pushing macros like move, we'd push move(int, int) in the pragma, which is not a valid macro name. As a result, we would not actually push macros like move -- instead we'd simply undefine them. This led to the following code not working: #define move HELLO #include <algorithm> // move is not HELLO anymore Fixing the pragma push/pop incantations led to a cascade of issues because we use identifiers like move in a large number of places, and all of these headers would now need to do the push/pop dance. This patch fixes all these issues. First, it adds a check that we don't swallow important names like min, max, move or refresh as explained above. This is done by augmenting the existing system_reserved_names.gen.py test to also check that the macros are what we expect after including each header. Second, it fixes the push/pop pragmas to work properly and adds missing pragmas to all the files I could detect a failure in via the newly added test. rdar://121365472 | 2 年前 | |
[libc++] Put _LIBCPP_NODEBUG on all internal aliases (#118710) This significantly reduces the amount of debug information generated for codebases using libc++, without hurting the debugging experience. | 1 年前 | |
[libc++] Fix missing and incorrect push/pop macros (#79204) We recently noticed that the unwrap_iter.h file was pushing macros, but it was pushing them again instead of popping them at the end of the file. This led to libc++ basically swallowing any custom definition of these macros in user code: #define min HELLO #include <algorithm> // min is not HELLO anymore, it's not defined While investigating this issue, I noticed that our push/pop pragmas were actually entirely wrong too. Indeed, instead of pushing macros like move, we'd push move(int, int) in the pragma, which is not a valid macro name. As a result, we would not actually push macros like move -- instead we'd simply undefine them. This led to the following code not working: #define move HELLO #include <algorithm> // move is not HELLO anymore Fixing the pragma push/pop incantations led to a cascade of issues because we use identifiers like move in a large number of places, and all of these headers would now need to do the push/pop dance. This patch fixes all these issues. First, it adds a check that we don't swallow important names like min, max, move or refresh as explained above. This is done by augmenting the existing system_reserved_names.gen.py test to also check that the macros are what we expect after including each header. Second, it fixes the push/pop pragmas to work properly and adds missing pragmas to all the files I could detect a failure in via the newly added test. rdar://121365472 | 2 年前 | |
[libc++][modules] Fix missing and incorrect includes (#108850) This patch adds a large number of missing includes in the libc++ headers and the test suite. Those were found as part of the effort to move towards a mostly monolithic top-level std module. | 1 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 9 个月前 | ||
| 2 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 8 个月前 | ||
| 10 个月前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 |