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