https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Keywords| |compile-time-hog,
| |memory-hog
Last reconfirmed| |2016-02-02
Component|c |rtl-optimization
CC| |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
Summary|block reordering consumes |[6 Regression] block
|an inordinate amount of |reordering consumes an
|time |inordinate amount of time,
| |REE consumes much memory
Target Milestone|--- |6.0
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Also takes a lot of memory with GCC 4.9 at least (killed at 2Gb). GCC 5 seems
to peak at ~1.6GB.
Note that with this kind of generated code I _always_ recommend -O1. -O2
simply
has too many quadraticnesses.
This case is a load of indirect jumps and loops and thus a very twisted CFG.
I'd say the number of BBs hits the BB reordering slowness.
First memory peak is for RTL pre (400MB), then rest_of_handle_ud_dce (800MB),
then REE (on trunk 2.1GB!). All basically DF issues.
It looks like we leak somewhere as well.
Thus first tracking the memory-use regression towards GCC 5 at -O2.
-O1 behaves reasonably (300MB memory use, 30sec compile-time for GCC 6), only
out-lier is
df live&initialized regs: 11.51 (39%) usr 0.08 ( 9%) sys 11.47 (37%) wall
0 kB ( 0%) ggc
well, we know DF is slow and memory hungry.
