http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59992
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> --- I think the issue for that is probably > ./cc1plus -quiet t.ii -O2 -ftime-report -m32 -Wdisabled-optimization ../../gcc/config/i386/sync.md: In function ‘int recog_102(rtx, rtx, int*)’: ../../gcc/config/i386/sync.md:518:1: warning: const/copy propagation disabled: 34779 basic blocks and 85328 registers [-Wdisabled-optimization] ../../gcc/config/i386/sync.md:518:1: warning: PRE disabled: 34779 basic blocks and 85328 registers [-Wdisabled-optimization] ../../gcc/config/i386/sync.md:518:1: warning: const/copy propagation disabled: 34779 basic blocks and 85328 registers [-Wdisabled-optimization] ../../gcc/config/i386/sync.md:518:1: warning: const/copy propagation disabled: 34536 basic blocks and 85329 registers [-Wdisabled-optimization] ... so we hit the self-imposed limits in cprop/gcse which then likely makes the compiler (the insn-recog part) very slow? As other parts of the compiler don't turn themselves off because of DF memory use at least the comment before this limit seems odd to me. (the compile still uses 1.7GB of ram for me). One issue is definitely the explicitely represented maximum set in lcm.c compute_available (and others - but that's used by both gcse and cprop).
