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.)