[Bug c++/27140] New: Compiling LLVM now takes nearly 5x as long with 4.1 as it did with 4.0
I'm compiling the LLVM compiler infrastructure and have noticed that GCC 4.1 takes an excessively long time to compile versus GCC 4.0. In particular, one file (albeit 2 million source lines) takes over 10 minutes (618.97 seconds) of CPU time to compile. On the exact same source, GCC 4.0.2 takes just over 2 minutes (130.68 seconds). GCC 3.4 was even faster (from memory). Here are the heavy-hitters (from -ftime-report) from highest to lowest: usr sys wall mem tree SSA incremental : 172.76 (30%) 0.61 ( 1%) 175.39 (22%) 9356kB ( 1%) ggc tree PHI insertion: 55.86 (10%) 0.30 ( 1%) 57.54 ( 7%) 6346kB ( 1%) ggc dominance frontiers : 40.15 ( 7%) 0.10 ( 0%) 40.02 ( 5%) 0kB ( 0%) ggc dominator optimization: 24.50 ( 4%) 0.57 ( 1%) 34.06 ( 4%) 74359kB ( 8%) ggc tree PTA : 19.51 ( 3%) 1.44 ( 3%) 22.90 ( 3%) 15806kB ( 2%) ggc PRE : 19.09 ( 3%) 6.52 (15%) 27.10 ( 3%) 1960kB ( 0%) ggc TOTAL : 576.55 42.42794.94 957564 kB Attached is a tarball that contains pre-compiled source code, and the timing statistics for both 4.0.2 and 4.1.0 as generated by GCC. This problem may have already been reported by or related to the following bugs: bug 18419, bug 17895, bug 17596. Another thing to note. The object file for 4.1.0 is 21% larger than for 4.0.2 (1454880 vs 1759292). Platform: (Linux FC3 with updates): Linux 2.6.12-1.1381_FC3smp #1 SMP Fri Oct 21 04:03:26 EDT 2005 i686 i686 i386 GNU/Linux gcc -v: (slow) Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1.0/configure --prefix=/proj/install --enable-languages=c,c++,java --with-gnuas --with-gnuld Thread model: posix gcc version 4.1.0 gcc -v: (fast) Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../svn/configure --prefix=/proj/install2 --enable-languages=c,c++ --with-gnuld --with-gnuas Thread model: posix gcc version 4.0.2 -- Summary: Compiling LLVM now takes nearly 5x as long with 4.1 as it did with 4.0 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rspencer at x10sys dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27140
[Bug c++/27140] Compiling LLVM now takes nearly 5x as long with 4.1 as it did with 4.0
--- Comment #1 from rspencer at x10sys dot com 2006-04-13 07:48 --- Created an attachment (id=11253) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11253&action=view) source code and -ftime-report output for both 4.0.2 and 4.1.0 This tarball contains 2MB of pre-compiled source code (slow.cpp) as well as two output files (slow.out=4.1.0 and fast.out=4.0.2). These contain the command lines used, the "gcc -v" output and the "gcc -ftime-report" output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27140
[Bug tree-optimization/27140] Compiling LLVM now takes nearly 5x as long with 4.1 as it did with 4.0
--- Comment #4 from rspencer at x10sys dot com 2006-04-13 17:26 --- Re: 2 million lines: Yes, my apologies for the late night blunder. It is 2,231,753 bytes and 79,037 lines. Re: large switch statements: There are several switch statements, none of them large. The largest is about 200 lines of code. None have more than 100 cases. The 200 line one only a few cases with some complex if/else code in each case. You'll have to look at the source yourself to get a better idea of "complex" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27140
[Bug tree-optimization/27140] Compiling LLVM now takes nearly 5x as long with 4.1 as it did with 4.0
--- Comment #5 from rspencer at x10sys dot com 2006-04-13 20:13 --- Created an attachment (id=11260) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11260&action=view) Timing results when using GCC 4.1.1 This attachment provides the -ftime-report output for the same compilation but with GCC 4.1.1 (prerelease). This takes about 1/2 the time as 4.1.0 but is still twice the time of 4.0.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27140
[Bug tree-optimization/27140] Compiling LLVM now takes nearly 5x as long with 4.1 as it did with 4.0
--- Comment #6 from rspencer at x10sys dot com 2006-04-13 20:30 --- Created an attachment (id=11261) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11261&action=view) Timing results with -fno-tree-salias Andrew Pinskia suggested that I try -fno-tree-salias. This decreased compilation time by about 10% (244 secs vs 265 secs). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27140
[Bug tree-optimization/27140] Compiling LLVM now takes nearly 5x as long with 4.1 as it did with 4.0
--- Comment #9 from rspencer at x10sys dot com 2006-04-21 23:12 --- Andrew Pinskia wanted me to mention that there are other source files in LLVM that exhibit the slow down. The one I attached is the worst offender, but there are others. Unfortunately, I don't remember which files and I removed GCC 4.1 from my system so I can't easily find out. If you build LLVM with GCC 4.1, you'll quickly discover which files are the slow ones. -- rspencer at x10sys dot com changed: What|Removed |Added CC| |rspencer at x10sys dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27140
[Bug tree-optimization/27140] Compiling LLVM now takes nearly 5x as long with 4.1 as it did with 4.0
--- Comment #10 from rspencer at x10sys dot com 2006-10-17 22:42 --- This is still a problem with: gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) Additionally, link times are much longer than with 3.4.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27140
[Bug libgcj/21326] New: _Jv_Linker
elaxng/util/TestDriver.java:21)
at gnu.java.lang.MainThread.call_main() (/proj/install/lib/libgcj.so.6.0.0)
at gnu.java.lang.MainThread.run() (/proj/install/lib/libgcj.so.6.0.0)
Caused by: java.lang.NullPointerException
at java.lang.VMClassLoader.resolveClass(java.lang.Class)
(/proj/install/lib/libgcj.so.6.0.0)
...11 more
--
Summary: _Jv_Linker
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rspencer at x10sys dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21326
[Bug libgcj/21326] seg fault in _Jv_Linker
--- Additional Comments From rspencer at x10sys dot com 2005-05-03 22:16 --- I don't see how that is possible on the application side as the source code is 100% Java and it is all compiled with the same options (there's only one compilation command that compiles all sources). Perhaps you are suggesting that libgcj is compiled differently from the application? If so, shouldn't the default compilation flags automatically work correctly with libgcj? The only flags given are "-g -02". So, I tried your suggestion. I compiled JING with HotSpot 1.4.2. It compiled fine to .class files via javac 1.4.2. I compiled the .class files (one command line again) with GCJ using the -findirect-dispatch option. GCJ gave hundreds of errors. Most of the errors were about "finalized field 'xyz' may not have been initialized". That sounds more like a warning to me, but I wouldn't know. I take it that GCJ doesn't like foreign compiled .class files? I'm not sure where to go from here except to give up on GCJ. Any other suggestions? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21326
[Bug libgcj/21326] seg fault in _Jv_Linker
--- Additional Comments From rspencer at x10sys dot com 2005-05-04 16:55 --- One other note. Shouldn't the segfault in _Jv_Linker be fixed anyway? Dereferencing a point of value 0x01 isn't likely to be valid in any circumstances? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21326
[Bug libgcj/21326] seg fault in _Jv_Linker
--- Additional Comments From rspencer at x10sys dot com 2005-05-04 19:48 --- Okay, after fixing some makefile bugs, the workaround suggested by Tom worked. Feel free to close this now unless you want to track down the SIGSEGV. Reid -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21326
[Bug c++/22121] New: Suspicious "may be used uninitialized" warning.
Andrew Pinskia asked me to file this. Warning message: CommandLine.h: In member function 'bool llvm::cl::opthttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=22121
[Bug c++/22121] Suspicious "may be used uninitialized" warning.
--- Additional Comments From rspencer at x10sys dot com 2005-06-19 15:57 --- Created an attachment (id=9112) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9112&action=view) Pre-processed compiler input This file contains the pre-processed input to the compiler from a source file in LLVM. It has not been reduced in any way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22121
