https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #24)
> Created attachment 50087 [details]
> updated time and memory report
>
> This is updated -f{time,mem}-report (with
> --enable-gather-detailed-mem-stats) for ltrans34.o
And the obvious candidate is the RD DF problem where DF-chain depends on RD.
Explicit RD users are haifa (sched_init (), but adds also DF-chain),
WEB, REE, loop IV and invariant and DCE.
df-problems.c:228 (df_rd_alloc) 1276M: 7.3% 1280M
33M: 1.6% 0 0 heap
df-problems.c:509 (df_rd_transfer_function) 6709M: 38.1% 6709M
329M: 15.6% 0 0 heap
df-problems.c:227 (df_rd_alloc) 7992M: 45.4% 7992M
200M: 9.5% 0 0 heap
but it's odd since in particular IRA does not seem to use DF_CHAIN/DF_RD
and at the start of ira() we do have 7GB RSS (for quite some time already,
somewhere in loop opt).
So the first peak to 7GB is fwprop_init, after add_phi_nodes. Memory
is released again after fwprop but since fwprop runs at -O1 it should
likely limit itself somehow. Richard?
The next pass is (meh), STV, which uses df_chain.
Then we have another fwprop instance.
Then remove_partial_avx_dependency and STV again, then if-conversion
but that doesn't use chain or rd - so sth from before must leak,
most likely one of the i386 specific passes after combine.
Looks like remove_partial_avx_dependency is the culprit, leaving garbage
around and for whatever stupid reason adds a plethora of DF problems...
