[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2

["steven at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326

--- Comment #39 from Steven Bosscher <steven at gcc dot gnu.org> 2013-03-07 23:18:48 UTC ---
Memory usage is still pathetic. Some stats:

mem stats from /proc/self/statm on *entry* of pass:

pass (#)                          size        resident   
*warn_unused_result ( -1)    177106944       140742656
...
*init_datastructures ( -1)   209670144       169570304
ssa ( 20)                    209670144       169582592
*rebuild_cgraph_edges ( -1)  302575616       259780608
...
expand (169)                 390647808       349757440
vregs (170)                  477892608       425406464
...
dfinit (174)                 477892608       425627648
cse1 (175)                   615616512       565694464 
...
dse1 (195)                   727654400       634572800
fwprop2 (196)                791678976       723767296
...
combine (200)                823115776       752177152 
ce2 (201)                   6589759488      6512082944 
...
csa (222)                   6938136576      1057169408

This means that "combine" explodes the memory foot print by ~5.4 GB.

On entry to combine, the memory foot print is ~750MB. I don't think
that is unreasonable. But after combine, the memory footprint jumps
to ~7GB max, and 350GB resident (after a ggc_collect before csa).
I'm guessing most of that 350GB is combine leaving memory scattered
so that pages can't be released.

dfinit is also a major contributor to the huge memory foot print.  I
have seen that in other test cases also, but so far I can't figure out
how it can consume this much memory.

Interestingly, the initial memory footprint, out of the front end, is
~180 MB. From there, the memory foot print gradually goes up, but that
is probably in part because ggc_collect is just never called (this is
on a box with 16GB RAM), with GGC params:

  --param ggc-min-expand=100 --param ggc-min-heapsize=131072

With both parameters halved, the combine problem obviously remains,
and the dfinit problem becomes more pronounced:

expand (169)                 328032256       287195136
vregs (170)                  474415104       424263680
...
dfinit (174)                 474415104       424484864
cse1 (175)                   613801984       564596736
...
combine (200)                823496704       752828416
ce2 (201)                   6590169088      6512717824

The good news: There clearly is a lot of room for improvement for this 
test case. :-)