[Bug c/67492] New: insn-attrtab and insn-automata for arm target neede huge amount of memory to generate/compile

["michael at weiser dot dinsnail.net" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67492

            Bug ID: 67492
           Summary: insn-attrtab and insn-automata for arm target neede
                    huge amount of memory to generate/compile
           Product: gcc
           Version: 4.9.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: michael at weiser dot dinsnail.net
  Target Milestone: ---

Created attachment 36305
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36305&action=edit
disable some CPU support in the arm target to reduce memory usage during
compiler compilation

I run Gentoo Linux on an embedded arm box with 128MB of RAM. This routinely
includes compiling gcc for it. Up to 4.9.3 that would require 400MB of swap and
take about two days. With 4.9.3 the situation has escalated in so far that even
500MB of swap aren't enough any more.

Upon closer inspection I found that generation and compilation of
insn-attrtab.c and insn-automata.c are huge memory hogs.

Instead of even trying to unserstand the internals of those, I've patched
support for all Cortex CPUs and some others out of the arm target to see what'd
happen to memory usage. This reduced the size of insn-attrtab.c from 1,1MB to
700KB and more noticeably insn-automata.c from 7,5MB to 160KB. Generation of
the source as well as compilation don't push the machine nearly as much into
the swap as before and compilation succeeds.

I suspect, 99% of people compiling their own compiler on a memory-constrained
box will only ever want to compile for that box. So is how hard would it be or
is there even some effort/patch to make gcc only compile in support for a
selected number of CPUs of a given target, indirectly reducing size of
insn-attrtab/insn-automata?

Incidentally: Is my patch likely to produce a seriously broken compiler? (It
seems fine so far.)