std::array with aggregate initialization on g++ generates huge code

by

There appears to be a related bug report, Bug 59659 – large zero-initialized std::array compile time excessive. It was considered “fixed” for 4.9.0, so I consider this testcase either a regression or an edgecase not covered by the patch. For what it’s worth, two of the bug report’s test cases1, 2 exhibit symptoms for me on both GCC 4.9.0 as well as 5.3.1

There are two more related bug reports:

Bug 68203 – Аbout infinite compilation time on struct with nested array of pairs with -std=c++11

Andrew Pinski 2015-11-04 07:56:57 UTC

This is most likely a memory hog which is generating lots of default
constructors rather than a loop over them.

That one claims to be a duplicate of this one:

Bug 56671 – Gcc uses large amounts of memory and processor power with large C++11 bitsets

Jonathan Wakely 2016-01-26 15:12:27 UTC

Generating the array initialization for this constexpr constructor is
the problem:

  constexpr _Base_bitset(unsigned long long __val) noexcept
  : _M_w{ _WordT(__val)
   } { }

Indeed if we change it to S a[4096] {}; we don’t get the problem.

Using perf we can see where GCC is spending most of its time. First:

perf record g++ -std=c++11 -O2 test.cpp

Then perf report:

  10.33%  cc1plus   cc1plus                 [.] get_ref_base_and_extent
   6.36%  cc1plus   cc1plus                 [.] memrefs_conflict_p
   6.25%  cc1plus   cc1plus                 [.] vn_reference_lookup_2
   6.16%  cc1plus   cc1plus                 [.] exp_equiv_p
   5.99%  cc1plus   cc1plus                 [.] walk_non_aliased_vuses
   5.02%  cc1plus   cc1plus                 [.] find_base_term
   4.98%  cc1plus   cc1plus                 [.] invalidate
   4.73%  cc1plus   cc1plus                 [.] write_dependence_p
   4.68%  cc1plus   cc1plus                 [.] estimate_calls_size_and_time
   4.11%  cc1plus   cc1plus                 [.] ix86_find_base_term
   3.41%  cc1plus   cc1plus                 [.] rtx_equal_p
   2.87%  cc1plus   cc1plus                 [.] cse_insn
   2.77%  cc1plus   cc1plus                 [.] record_store
   2.66%  cc1plus   cc1plus                 [.] vn_reference_eq
   2.48%  cc1plus   cc1plus                 [.] operand_equal_p
   1.21%  cc1plus   cc1plus                 [.] integer_zerop
   1.00%  cc1plus   cc1plus                 [.] base_alias_check

This won’t mean much to anyone but GCC developers but it’s still interesting to see what’s taking up so much compilation time.

Clang 3.7.0 does a much better job at this than GCC. At -O2 it takes less than a second to compile, produces a much smaller executable (8960 bytes) and this assembly:

0000000000400810 <main>:
  400810:   53                      push   rbx
  400811:   48 81 ec 00 40 00 00    sub    rsp,0x4000
  400818:   48 8d 3c 24             lea    rdi,[rsp]
  40081c:   31 db                   xor    ebx,ebx
  40081e:   31 f6                   xor    esi,esi
  400820:   ba 00 40 00 00          mov    edx,0x4000
  400825:   e8 56 fe ff ff          call   400680 <memset@plt>
  40082a:   66 0f 1f 44 00 00       nop    WORD PTR [rax+rax*1+0x0]
  400830:   f3 0f 10 04 1c          movss  xmm0,DWORD PTR [rsp+rbx*1]
  400835:   f3 0f 5a c0             cvtss2sd xmm0,xmm0
  400839:   bf 60 10 60 00          mov    edi,0x601060
  40083e:   e8 9d fe ff ff          call   4006e0 <_ZNSo9_M_insertIdEERSoT_@plt>
  400843:   48 83 c3 04             add    rbx,0x4
  400847:   48 81 fb 00 40 00 00    cmp    rbx,0x4000
  40084e:   75 e0                   jne    400830 <main+0x20>
  400850:   31 c0                   xor    eax,eax
  400852:   48 81 c4 00 40 00 00    add    rsp,0x4000
  400859:   5b                      pop    rbx
  40085a:   c3                      ret    
  40085b:   0f 1f 44 00 00          nop    DWORD PTR [rax+rax*1+0x0]

On the other hand with GCC 5.3.1, with no optimizations, it compiles very quickly but still produces a 95328 sized executable. Compiling with -O2 reduces the executable size to 53912 but compilation time takes 4 seconds. I would definitely report this to their bugzilla.

More Related Contents:

  1. Different floating point result with optimization enabled – compiler bug?
  2. How to use profile guided optimizations in g++?
  3. Is optimisation level -O3 dangerous in g++?
  4. List of common C++ Optimization Techniques [closed]
  5. How to compile a program with limit time (5s), using MinGW-Gnu C++
  6. Undefined reference to static class member
  7. Why does C++ code for testing the Collatz conjecture run faster than hand-written assembly?
  8. Meaning of acronym SSO in the context of std::string
  9. Position of least significant bit that is set
  10. Compiling C++11 with g++
  11. Is “for(;;)” faster than “while (true)”? If not, why do people use it?
  12. Error: free(): invalid next size (fast):
  13. How does #include work in C++? [duplicate]
  14. Deoptimizing a program for the pipeline in Intel Sandybridge-family CPUs
  15. GNU GCC (g++): Why does it generate multiple dtors?
  16. How to read file content into istringstream?
  17. What kinds of optimizations does ‘volatile’ prevent in C++?
  18. How to make G++ preprocessor output a newline in a macro?
  19. Self-unrolling macro loop in C/C++
  20. What is the VTable Layout and VTable Pointer Location in C++ Objects in GCC 3.x and 4.x?
  21. How to solve ——-undefined reference to `__chkstk_ms’——-on mingw
  22. OpenCV 2.3 Compiling Issue – Undefined Refence – Ubuntu 11.10
  23. Move or Named Return Value Optimization (NRVO)?
  24. What is a .h.gch file?
  25. Optimizing member variable order in C++
  26. Do I really have to worry about alignment when using placement new operator?
  27. Why can’t I use with g++ 4.9.2?
  28. How can adding code to a loop make it faster?
  29. Why does stack not compile in g++? [duplicate]
  30. Eclipse C++ : “Program “g++” not found in PATH”

Leave a Comment