[Bug libstdc++/110167] excessive compile time for std::to_array with huge arrays

2024-03-13 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #15 from Jonathan Wakely  ---
Fixed for 13.3 and 12.4

[Bug libstdc++/110167] excessive compile time for std::to_array with huge arrays

2024-03-13 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167

--- Comment #14 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:ec5da76ad33dcba7858525fdb6b39288631fcd8a

commit r12-10206-gec5da76ad33dcba7858525fdb6b39288631fcd8a
Author: Jonathan Wakely 
Date:   Thu Jun 8 12:24:43 2023 +0100

libstdc++: Optimize std::to_array for trivial types [PR110167]

As reported in PR libstdc++/110167, std::to_array compiles extremely
slowly for very large arrays. It needs to instantiate a very large
specialization of std::index_sequence and then create a very large
aggregate initializer from the pack expansion. For trivial types we can
simply default-initialize the std::array and then use memcpy to copy the
values. For non-trivial types we need to use the existing
implementation, despite the compilation cost.

As also noted in the PR, using a generic lambda instead of the
__to_array helper compiles faster since gcc-13. It also produces
slightly smaller code at -O1, due to additional inlining. The code at
-Os, -O2 and -O3 seems to be the same. This new implementation requires
__cpp_generic_lambdas >= 201707L (i.e. P0428R2) but that is supported
since Clang 10 and since Intel icc 2021.5.0 (and since GCC 10.1).

libstdc++-v3/ChangeLog:

PR libstdc++/110167
* include/std/array (to_array): Initialize arrays of trivial
types using memcpy. For non-trivial types, use lambda
expressions instead of a separate helper function.
(__to_array): Remove.
* testsuite/23_containers/array/creation/110167.cc: New test.

(cherry picked from commit 960de5dd886572711ef86fa1e15e30d3810eccb9)

[Bug libstdc++/110167] excessive compile time for std::to_array with huge arrays

2024-03-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167

--- Comment #13 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:4c6bb36e88d5c8e510b10d12c01e3461c2aa4259

commit r13-8421-g4c6bb36e88d5c8e510b10d12c01e3461c2aa4259
Author: Jonathan Wakely 
Date:   Thu Jun 8 12:24:43 2023 +0100

libstdc++: Optimize std::to_array for trivial types [PR110167]

As reported in PR libstdc++/110167, std::to_array compiles extremely
slowly for very large arrays. It needs to instantiate a very large
specialization of std::index_sequence and then create a very large
aggregate initializer from the pack expansion. For trivial types we can
simply default-initialize the std::array and then use memcpy to copy the
values. For non-trivial types we need to use the existing
implementation, despite the compilation cost.

As also noted in the PR, using a generic lambda instead of the
__to_array helper compiles faster since gcc-13. It also produces
slightly smaller code at -O1, due to additional inlining. The code at
-Os, -O2 and -O3 seems to be the same. This new implementation requires
__cpp_generic_lambdas >= 201707L (i.e. P0428R2) but that is supported
since Clang 10 and since Intel icc 2021.5.0 (and since GCC 10.1).

libstdc++-v3/ChangeLog:

PR libstdc++/110167
* include/std/array (to_array): Initialize arrays of trivial
types using memcpy. For non-trivial types, use lambda
expressions instead of a separate helper function.
(__to_array): Remove.
* testsuite/23_containers/array/creation/110167.cc: New test.

(cherry picked from commit 960de5dd886572711ef86fa1e15e30d3810eccb9)

[Bug libstdc++/110167] excessive compile time for std::to_array with huge arrays

2023-10-19 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |12.4

[Bug libstdc++/110167] excessive compile time for std::to_array with huge arrays

2023-06-09 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:960de5dd886572711ef86fa1e15e30d3810eccb9

commit r14-1647-g960de5dd886572711ef86fa1e15e30d3810eccb9
Author: Jonathan Wakely 
Date:   Thu Jun 8 12:24:43 2023 +0100

libstdc++: Optimize std::to_array for trivial types [PR110167]

As reported in PR libstdc++/110167, std::to_array compiles extremely
slowly for very large arrays. It needs to instantiate a very large
specialization of std::index_sequence and then create a very large
aggregate initializer from the pack expansion. For trivial types we can
simply default-initialize the std::array and then use memcpy to copy the
values. For non-trivial types we need to use the existing
implementation, despite the compilation cost.

As also noted in the PR, using a generic lambda instead of the
__to_array helper compiles faster since gcc-13. It also produces
slightly smaller code at -O1, due to additional inlining. The code at
-Os, -O2 and -O3 seems to be the same. This new implementation requires
__cpp_generic_lambdas >= 201707L (i.e. P0428R2) but that is supported
since Clang 10 and since Intel icc 2021.5.0 (and since GCC 10.1).

libstdc++-v3/ChangeLog:

PR libstdc++/110167
* include/std/array (to_array): Initialize arrays of trivial
types using memcpy. For non-trivial types, use lambda
expressions instead of a separate helper function.
(__to_array): Remove.
* testsuite/23_containers/array/creation/110167.cc: New test.

[Bug libstdc++/110167] excessive compile time for std::to_array with huge arrays

2023-06-09 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167

--- Comment #11 from Richard Biener  ---
It's also very bad for code size, so yes, a loopy implementation is very
much prefered even for a much smaller threshold than 1024!

[Bug libstdc++/110167] excessive compile time for std::to_array with huge arrays

2023-06-08 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167

--- Comment #10 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #6)
>   if constexpr (_Nm > 1024 && is_trivially_default_constructible_v<_Tp>
> && is_trivially_assignable_v<_Tp&, _Tp&>)
>   {
> array<_Tp, _Nm> __arr;
> for (size_t __i = 0; __i < _Nm; ++i)
>   __arr[__i] = __a[__i];
> return __arr;

I wonder if we should do this for any N, and rely on the compiler to DTRT for
the loop.

[Bug libstdc++/110167] excessive compile time for std::to_array with huge arrays

2023-06-08 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167

Jonathan Wakely  changed:

   What|Removed |Added

Summary|excessive compile time when |excessive compile time for
   |optimizing std::to_array|std::to_array with huge
   ||arrays

--- Comment #9 from Jonathan Wakely  ---
Adjusting the misleading title though, as optimization makes it worse, but the
problem exists even at -O0