Created attachment 28061 [details]
The attached file contains a few function definitions followed by a main method
with a single line of code duplicated 2500 times.
At optimization levels O0, the code compiles relatively quickly (~8s).
However, at optimization levels O2 and O3, the compilation time jumps to over 30s to compile -- almost a 4x difference.
Interesting things about what speeds up the optimized compilation:
Having an if-statement with an empty body cuts down compilation times on all
optimization levels to under 3s.
This could be related to http://llvm.org/bugs/show_bug.cgi?id=13651, as the problem was discovered in a file that repeats a macro heavily, as these examples do.
For me it does not even compile:
t1.cc:44:36: error: ‘numeric_limits’ is not a member of ‘std’
expected_ss << std::setprecision(std::numeric_limits<float>::digits10);
Created attachment 28062 [details]
Linux-compatible test case
The original test case was timed and compiled on a Mac. This one shows a much less extreme version of the problem (only goes from 2.5 seconds to 5 seconds).
The original problem was found as part of the gtest framework and was slow on all architectures. I will try to manufacture a version that better showcases the original problem in the meanwhile.
Created attachment 28063 [details]
Linux-compatible test case
$ time g++ -O3 -c t2.cc
$ time g++ -O0 -c t2.cc
On both Linux and Mac, this type of discrepancy exists.
Can you please provide the output of your "gcc --version" and of a compiler run with the extra flag "-ftime-report"?
Sort-of "confirmed", though you should expect compile-time increases from -O0 to
-O and I don't think the increases are unreasonable, esp. for C++ code which
can see a lot if inlining.
> /usr/bin/time g++-4.7 -S -o /dev/null t.C -O0
2.24user 0.09system 0:02.84elapsed 82%CPU (0avgtext+0avgdata 918736maxresident)k
22384inputs+0outputs (97major+62614minor)pagefaults 0swaps
> /usr/bin/time g++-4.7 -S -o /dev/null t.C -O1
11.24user 0.15system 0:11.43elapsed 99%CPU (0avgtext+0avgdata 1045616maxresident)k
0inputs+0outputs (0major+113102minor)pagefaults 0swaps
> /usr/bin/time g++-4.7 -S -o /dev/null t.C -O2
16.67user 0.38system 0:17.12elapsed 99%CPU (0avgtext+0avgdata 1189056maxresident)k
2504inputs+0outputs (11major+199132minor)pagefaults 0swaps
> /usr/bin/time g++-4.7 -S -o /dev/null t.C -O3
17.79user 0.30system 0:18.20elapsed 99%CPU (0avgtext+0avgdata 1203280maxresident)k
328inputs+0outputs (2major+200860minor)pagefaults 0swaps
alias stmt walking : 2.87 (16%) usr 0.02 ( 4%) sys 2.96 (16%) wall 1 kB ( 0%) ggc
tree PTA : 4.59 (26%) usr 0.01 ( 2%) sys 4.63 (25%) wall 1313 kB ( 1%) ggc
so I think we have a duplicate for this kind of issue. SCCVN walks over
non-aliased stores are not limited and can expose quadratic complexity
if there are no aliases in the function that stop the walk. PR46590
comes to my mind which already tracks this.
*** This bug has been marked as a duplicate of bug 46590 ***