[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1

2021-05-14 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Status|NEW |RESOLVED
   Target Milestone|8.5 |9.0
 Resolution|--- |FIXED

--- Comment #10 from Jakub Jelinek  ---
The GCC 8 branch is being closed, fixed in GCC 9.1.

[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1

2020-03-04 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.4 |8.5

--- Comment #9 from Jakub Jelinek  ---
GCC 8.4.0 has been released, adjusting target milestone.

[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1

2019-11-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.5 |8.4

--- Comment #8 from Richard Biener  ---
The GCC 7 branch is being closed, re-targeting to GCC 8.4.

[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1

2019-10-22 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #7 from Martin Liška  ---
Started probably in r228194 (change from 400MB -> 1400MB RAM usage).

[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1

2019-02-15 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||marxin at gcc dot gnu.org
  Known to work|6.4.0   |8.2.0, 9.0
  Known to fail||6.4.0

--- Comment #6 from Martin Liška  ---
Fixed on trunk in r251412 which is a revision where I introduced switch
expansion as a GIMPLE pass.

[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1

2018-12-06 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.4 |7.5

[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1

2018-11-22 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Last reconfirmed|2017-10-02 00:00:00 |2018-11-22

--- Comment #5 from Richard Biener  ---
Reconfirmed on x86_64-linux - -m32 -march=i586 is the key:

>  /usr/bin/time gcc-7 piglit-util-gl-enum-gen.i -S -O -m323.17user 0.03system 
> 0:03.21elapsed 100%CPU (0avgtext+0avgdata 83788maxresident)k
0inputs+1448outputs (0major+20119minor)pagefaults 0swaps
> /usr/bin/time gcc-7 piglit-util-gl-enum-gen.i -S -O -m32 -march=i586
4.85user 0.48system 0:05.34elapsed 99%CPU (0avgtext+0avgdata
1388540maxresident)k
0inputs+1288outputs (0major+389610minor)pagefaults 0swaps
> /usr/bin/time gcc-7 piglit-util-gl-enum-gen.i -S -O2 -m32 -march=i586
7.35user 1.89system 0:09.25elapsed 99%CPU (0avgtext+0avgdata
6201368maxresident)k
0inputs+1232outputs (0major+1688989minor)pagefaults 0swaps
> /usr/bin/time gcc-7 piglit-util-gl-enum-gen.i -S -O3 -m32 -march=i586
7.51user 1.79system 0:09.30elapsed 99%CPU (0avgtext+0avgdata
6201424maxresident)k
8inputs+1392outputs (0major+1689484minor)pagefaults 0swaps
> /usr/bin/time gcc-8 piglit-util-gl-enum-gen.i -S -O3 -m32 -march=i586
2.39user 0.08system 0:02.48elapsed 99%CPU (0avgtext+0avgdata
133140maxresident)k
1632inputs+1552outputs (1major+66249minor)pagefaults 0swaps

somehow feels like a memory leak.  Well, mem-report shows the following.

simplify-rtx.c:403 (simplify_gen_ternary)  15636000:  2.3% 0: 
0.0% 0:  0.0% 0:  0.0%488625
emit-rtl.c:1087 (ensure_regno_capacity)   0:  0.0%  21294000: 
8.1%  21299200: 31.7%   9042864: 94.6%13
rtlanal.c:5564 (canonicalize_condition)23604360:  3.4% 0: 
0.0% 0:  0.0% 0:  0.0%983515
config/i386/i386.c:22616 (ix86_expand_int_compar   58644264:  8.5% 0: 
0.0%100944:  0.2% 0:  0.0%   2447717
config/i386/i386.c:22617 (ix86_expand_int_compar   58644264:  8.5% 0: 
0.0%100944:  0.2% 0:  0.0%   2447717
config/i386/i386.c:22621 (ix86_expand_int_compar   58644264:  8.5% 0: 
0.0%100944:  0.2% 0:  0.0%   2447717
optabs.c:3863 (prepare_cmp_insn)   58745208:  8.5% 0: 
0.0% 0:  0.0% 0:  0.0%   2447717
simplify-rtx.c:419 (simplify_gen_relational)   58745304:  8.5% 0: 
0.0% 0:  0.0% 0:  0.0%   2447721
rtl.c:319 (copy_rtx)   64517840:  9.3% 0: 
0.0%24:  0.0% 0:  0.0%   1466370
emit-rtl.c:436 (gen_raw_REG)   58772328:  8.5%24: 
0.0%  23521224: 35.0% 0:  0.0%   3428899
emit-rtl.c:3864 (make_insn_raw)   218936256: 31.6% 0: 
0.0%497152:  0.7% 0:  0.0%   3428647

would be interesting to see what fixed it on the GCC 8 branch.  Generated
code seems to be similar.

[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1

2018-01-25 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #4 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1

2017-12-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.4.0
  Known to fail||7.2.0

--- Comment #3 from Richard Biener  ---
I can't reproduce with GCC 7.2.0 or 7.2.1 r253932 on x86_64 with -O[12] -m32:

> /usr/bin/time /space/rguenther/install/gcc-7.2/bin/gcc 
> piglit-util-gl-enum-gen.i -S -m32 -O
3.33user 0.02system 0:03.35elapsed 100%CPU (0avgtext+0avgdata
84760maxresident)k
0inputs+1416outputs (0major+17649minor)pagefaults 0swaps
> /usr/bin/time /space/rguenther/install/gcc-7.2/bin/gcc 
> piglit-util-gl-enum-gen.i -S -m32 -O2
4.37user 0.04system 0:04.44elapsed 99%CPU (0avgtext+0avgdata
103948maxresident)k
2384inputs+1232outputs (4major+33840minor)pagefaults 0swaps


Note that specifying -march=i586 increases memory use quite a bit (10x):

> /usr/bin/time /space/rguenther/install/gcc-7.2/bin/gcc 
> piglit-util-gl-enum-gen.i -S -m32 -O -march=i586
5.28user 0.39system 0:05.68elapsed 99%CPU (0avgtext+0avgdata
1389360maxresident)k
0inputs+1288outputs (0major+390160minor)pagefaults 0swaps

but I see similar values with GCC 6:

> /usr/bin/time /space/rguenther/install/gcc-6.4/bin/gcc 
> piglit-util-gl-enum-gen.i -S -m32 -O -march=i586
4.47user 0.31system 0:05.16elapsed 92%CPU (0avgtext+0avgdata
1030020maxresident)k
39416inputs+1288outputs (43major+293486minor)pagefaults 0swaps


so - please report the GCC output for the "failing" case when you append -v
to the command.

[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1

2017-10-02 Thread bunk at stusta dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364

Adrian Bunk  changed:

   What|Removed |Added

Summary|[7 Regression] Enormous |[7 Regression] Enormous
   |memory usage when building  |memory usage when building
   |on 32bit i386 with >= -O1   |for 32bit i386 with >= -O1

--- Comment #2 from Adrian Bunk  ---
(In reply to Richard Biener from comment #1)
> Can you provide output of the compile command with -v appended so we can see
> the different default flags passed for both the 32bit compile and the 64bit
> -m32 compile?

Thanks for asking, looking at the output I realized that I made the stupid
mistake of running gcc 6 in the 64bit -m32 compile.

The 64bit -m32 compile succeeds with gcc-7, but it actually has 5.5 GB memory
usage.