https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #30 from Richard Biener <rguenth at gcc dot gnu.org> --- Temporarily memory goes to out-of-SSA computing liveness (2GB), after RTL expansion it drops to ~900MB peak again. Then df-init-at-O0 bumps to 1.3GB and then IRA goes all the way to >3GB. We're using lra_simple_p because num_used_regs is 343033 and last_basic_block is 117142. It's df_analyze () which brings memory usage to 2.8GB. After ira_build () it's 3.4GB. There's 1.5GB used in LR problem data bitmaps, we are not separating the local computed bitmaps from the global solution (the DF machinery doesn't have a separate "local compute" free, possibly the finalize hook can be used for this). Though the local compute bitmaps only use around 20MB. The DF bitmap obstack itself is quite small as well. Of course it's all because we fail to implement the initializers EH cleanup in a more sensible way. Complete "elements" could be processed in a loop over the containers elements while only a single partially under-construction element would need to be handled "inline".
