[patch] PR29442 - split insn-attrtab.c in three parts

[Steven Bosscher <stevenb dot gcc at gmail dot com>]

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

Attachment: pr29442-split.diff
Description: Binary data