Hello, How does one turn random volunteer GCC hackers into spoiled brats? Give them Big Iron to play with, like IBM's donation to the compile farm aka gcc110. If you do "make -k 64" on a machine like that, a GCC build takes _minutes_, and that's sooooo slooooooow...
Part of the problem is insn-attrtab.c, which is huge: 174985 lines of pure C without comment for trunk r187046 on x86_64 (and even more if you run GNU indent over it). In a parallel build, this file is a serious bottle neck. Then, the other day, I saw a message about PR29442 on gcc-bugs@, and I found a patch from Rask there to split insn-attrtab.c into three files. It needed some TLC but the idea looks really good to me. All internal_dfa_insn_code_* functions go into insn-dfatab.c, all insn_default_latency_* functions go into insn-latencytab.c, and the rest goes to insn-attrtab.c as before. For x86_64 this results in three roughly equal-size files: $ wc gcc/insn-*tab.c 39225 146718 1250434 gcc/insn-attrtab.c 77665 338918 2769362 gcc/insn-dfatab.c 58170 240789 2029351 gcc/insn-latencytab.c 175060 726425 6049147 total This patch is perhaps a bit hackish, but there are good pay-offs: Parallel build can now build 3 files simultaneously (genattrtab is still slow, unfortunately) and the peak memory consumption for a GCC build (that currently occurs while compiling insn-attrtab.c) goes down significantly. The memory footprint is apparently an issue for smaller/older machines, because the original complaint in PR29442 concerned peak memory usage while building GCC. This patch was bootstrapped on x86_64-unknown-linux-gnu. OK for trunk? Ciao! Steven
pr29442-split.diff
Description: Binary data