[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case

2019-04-06 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 --- Comment #20 from Dominique d'Humieres --- Updated timings % gfc6 -c pr80960.f90 -fdefault-integer-8 -O2 -ftime-report ... combiner: 81.12 (55%) usr 1.17 (41%) sys 82.31 (54%) wall 2700699 kB (60%) ggc ... TOTAL

[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case

2019-04-05 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 --- Comment #19 from Segher Boessenkool --- (In reply to rguent...@suse.de from comment #18) > Hmm, so if we'd have numbered stmts in an EBB we could check the > distance between set and use and not combine when that gets too big? Yeah. Or we

[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case

2019-04-05 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 --- Comment #18 from rguenther at suse dot de --- On Thu, 4 Apr 2019, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 > > --- Comment #17 from Segher Boessenkool --- > (In reply to rguent...@suse.de from

[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case

2019-04-03 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 --- Comment #17 from Segher Boessenkool --- (In reply to rguent...@suse.de from comment #16) > I would guess so. I wonder if the combiner could restrict itself > here? Maybe LUID "distances" are an approximation? Doesn't the > combiner use

[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case

2019-04-03 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 --- Comment #16 from rguenther at suse dot de --- On Tue, 2 Apr 2019, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 > > --- Comment #15 from Segher Boessenkool --- > It seems to be that this happens for

[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case

2019-04-02 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 --- Comment #15 from Segher Boessenkool --- It seems to be that this happens for huge basic blocks, and the combiner tries to combine pairs of instructions that are far apart. This is unlikely to work often, and the cost is quadratic in #

[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case

2019-04-01 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 --- Comment #14 from rguenther at suse dot de --- On Sun, 31 Mar 2019, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 > > --- Comment #13 from Thomas Koenig --- > With -O2, the combiner takes up quite a

[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case

2019-03-31 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 --- Comment #13 from Thomas Koenig --- With -O2, the combiner takes up quite a lot of time: $ time gfortran -ftime-report -g0 -O2 -fdefault-integer-8 -c fe_objective.f90 alias stmt walking : 15.75 ( 4%) 0.11 ( 5%) 15.89

[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case

2018-12-06 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 Richard Biener changed: What|Removed |Added Target Milestone|7.4 |7.5