public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug rtl-optimization/63191] New: 32-bit gcc uses excessive memory during dead store elimination with -fPIC
@ 2014-09-05 20:12 woodfin at intersystems dot com
2014-09-08 9:01 ` [Bug rtl-optimization/63191] [4.8/4.9/5 Regression] " rguenth at gcc dot gnu.org
` (9 more replies)
0 siblings, 10 replies; 11+ messages in thread
From: woodfin at intersystems dot com @ 2014-09-05 20:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191
Bug ID: 63191
Summary: 32-bit gcc uses excessive memory during dead store
elimination with -fPIC
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: woodfin at intersystems dot com
Created attachment 33453
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33453&action=edit
Source triggering memory usage
Every version of gcc I try from 4.4 -> 4.9.1 on 32-bit Linux uses excessive
memory (eventually exhausting all 3GB of virtual address space) when I compile
the attached (generated, simplified) source with
g++ -c -O2 -fPIC badmatch.cpp
4.3 does not exhibit the issue.
64-bit Linux (gcc 4.4.4 in that case) does not exhibit the issue, and memory
usage tops out at ~440MB. gcc 4.4.4 on 32-bit Linux does exhibit the issue.
Dropping -fPIC causes memory usage to top out at ~175MB and the compile to
succeed.
-no-dse eliminates the problem as well.
A look at the mallocs in the debugger suggests that the explosion of
allocations is happening under rest_of_handle_dse(), e.g.:
#0 0x00332e46 in malloc () from /lib/libc.so.6
#1 0x08a26148 in xmalloc ()
#2 0x0829285b in pool_alloc(alloc_pool_def*) () at
../.././gcc/alloc-pool.c:281
#3 0x082f076e in cselib_lookup(rtx_def*, machine_mode, int, machine_mode) ()
at ../.././gcc/cselib.c:1303
#4 0x089536e2 in canon_address(rtx_def*, int*, int*, long long*, cselib_val**)
() at ../.././gcc/dse.c:1182
#5 0x08954770 in record_store(rtx_def*, bb_info*) () at ../.././gcc/dse.c:1443
#6 0x08955e6a in rest_of_handle_dse() () at ../.././gcc/dse.c:2616
#7 0x084bd923 in execute_one_pass(opt_pass*) () at ../.././gcc/passes.c:2233
The most recent version with which I have tested:
>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/nethome/woodfin/opt/lnxrhx86/gcc-4.9.1/libexec/gcc/i686-pc-linux-gnu/4.9.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/nethome/woodfin/opt/lnxrhx86/gcc-4.9.1
--enable-languages=c,c++ --with-mpfr=/nethome/woodfin/opt/lnxrhx86/mpfr-2.4.2
--with-gmp=/nethome/woodfin/opt/lnxrhx86/gmp-4.3.2
--with-mpc=/nethome/woodfin/opt/lnxrhx86/mpc-1.0.2
Thread model: posix
gcc version 4.9.1 (GCC)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC 2014-09-05 20:12 [Bug rtl-optimization/63191] New: 32-bit gcc uses excessive memory during dead store elimination with -fPIC woodfin at intersystems dot com @ 2014-09-08 9:01 ` rguenth at gcc dot gnu.org 2014-11-24 13:18 ` rguenth at gcc dot gnu.org ` (8 subsequent siblings) 9 siblings, 0 replies; 11+ messages in thread From: rguenth at gcc dot gnu.org @ 2014-09-08 9:01 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191 --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- With int a, b, c, d; struct X { int a; int b; void *p; } z[4]; void foo (void) { z[0].a = 1; z[0].b = 2; z[0].p = &a; z[1].a = 1; z[1].b = 2; z[1].p = &b; z[2].a = 1; z[2].b = 2; z[2].p = &c; z[3].a = 1; z[3].b = 2; z[3].p = &d; } CSEing of the GOT load of z works. ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC 2014-09-05 20:12 [Bug rtl-optimization/63191] New: 32-bit gcc uses excessive memory during dead store elimination with -fPIC woodfin at intersystems dot com 2014-09-08 9:01 ` [Bug rtl-optimization/63191] [4.8/4.9/5 Regression] " rguenth at gcc dot gnu.org @ 2014-11-24 13:18 ` rguenth at gcc dot gnu.org 2014-12-19 13:27 ` jakub at gcc dot gnu.org ` (7 subsequent siblings) 9 siblings, 0 replies; 11+ messages in thread From: rguenth at gcc dot gnu.org @ 2014-11-24 13:18 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P2 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC 2014-09-05 20:12 [Bug rtl-optimization/63191] New: 32-bit gcc uses excessive memory during dead store elimination with -fPIC woodfin at intersystems dot com 2014-09-08 9:01 ` [Bug rtl-optimization/63191] [4.8/4.9/5 Regression] " rguenth at gcc dot gnu.org 2014-11-24 13:18 ` rguenth at gcc dot gnu.org @ 2014-12-19 13:27 ` jakub at gcc dot gnu.org 2015-04-07 20:23 ` steven at gcc dot gnu.org ` (6 subsequent siblings) 9 siblings, 0 replies; 11+ messages in thread From: jakub at gcc dot gnu.org @ 2014-12-19 13:27 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.8.4 |4.8.5 --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- GCC 4.8.4 has been released. ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC 2014-09-05 20:12 [Bug rtl-optimization/63191] New: 32-bit gcc uses excessive memory during dead store elimination with -fPIC woodfin at intersystems dot com ` (2 preceding siblings ...) 2014-12-19 13:27 ` jakub at gcc dot gnu.org @ 2015-04-07 20:23 ` steven at gcc dot gnu.org 2015-04-07 20:42 ` woodfin at intersystems dot com ` (5 subsequent siblings) 9 siblings, 0 replies; 11+ messages in thread From: steven at gcc dot gnu.org @ 2015-04-07 20:23 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191 --- Comment #4 from Steven Bosscher <steven at gcc dot gnu.org> --- How is one to reproduce this bug with GCC5? I've tried: $ ./xg++ --version xg++ (GCC) 5.0.0 20150407 (experimental) [trunk revision 221906] Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ./xg++ -B. -S -O2 -m32 -fPIC PR63191.cc -fdump-tree-optimized $ cat PR63191.cc.190t.optimized ;; Function (static initializers for PR63191.cc) (_GLOBAL__sub_I_PR63191.cc, funcdef_no=4, decl_uid=14028, cgraph_uid=4, symbol_order=1500) (executed once) (static initializers for PR63191.cc) () { <bb 2>: return; } $ So AFAICT GCC5 optimizes the test case of comment #0 to an empty file. I'm sure there's a way to avoid optimizing this to empty, but I'm not quite a C++ guru ;-) ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC 2014-09-05 20:12 [Bug rtl-optimization/63191] New: 32-bit gcc uses excessive memory during dead store elimination with -fPIC woodfin at intersystems dot com ` (3 preceding siblings ...) 2015-04-07 20:23 ` steven at gcc dot gnu.org @ 2015-04-07 20:42 ` woodfin at intersystems dot com 2015-04-07 21:30 ` steven at gcc dot gnu.org ` (4 subsequent siblings) 9 siblings, 0 replies; 11+ messages in thread From: woodfin at intersystems dot com @ 2015-04-07 20:42 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191 --- Comment #5 from woodfin at intersystems dot com --- You could try adding a non-static function that returns an address inside Zs. const Z* getzs() { return &Zs[0]; } I'd think that would force it to actually perform the initialization if the contents can be externally accessed. Sorry, I don't have a gcc 5.0 environment yet. I'll set one up if you still can't reproduce this there. ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC 2014-09-05 20:12 [Bug rtl-optimization/63191] New: 32-bit gcc uses excessive memory during dead store elimination with -fPIC woodfin at intersystems dot com ` (4 preceding siblings ...) 2015-04-07 20:42 ` woodfin at intersystems dot com @ 2015-04-07 21:30 ` steven at gcc dot gnu.org 2015-04-07 21:39 ` steven at gcc dot gnu.org ` (3 subsequent siblings) 9 siblings, 0 replies; 11+ messages in thread From: steven at gcc dot gnu.org @ 2015-04-07 21:30 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191 --- Comment #6 from Steven Bosscher <steven at gcc dot gnu.org> --- (In reply to woodfin from comment #5) > You could try adding a non-static function that returns an address inside Zs. > > const Z* getzs() { > return &Zs[0]; > } Yes, that does the trick: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 25244 stevenb 20 0 5964m 5.8g 30m R 100 9.3 25:03.60 cc1plus (and counting) Now let's see if I can come up with a more reasonable test case... ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC 2014-09-05 20:12 [Bug rtl-optimization/63191] New: 32-bit gcc uses excessive memory during dead store elimination with -fPIC woodfin at intersystems dot com ` (5 preceding siblings ...) 2015-04-07 21:30 ` steven at gcc dot gnu.org @ 2015-04-07 21:39 ` steven at gcc dot gnu.org 2015-06-23 8:20 ` [Bug rtl-optimization/63191] [4.8/4.9/5/6 " rguenth at gcc dot gnu.org ` (2 subsequent siblings) 9 siblings, 0 replies; 11+ messages in thread From: steven at gcc dot gnu.org @ 2015-04-07 21:39 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191 --- Comment #7 from Steven Bosscher <steven at gcc dot gnu.org> --- (In reply to Steven Bosscher from comment #6) > Now let's see if I can come up with a more reasonable test case... Like so: ----- 8< ----- typedef int X; struct Z { Z(const X* x1, X x2, X x3) : x1_(x1), x2_(x2), x3_(x3) {} const X* x1_; X x2_; X x3_; }; #undef X____1 #undef X___10 #undef X__100 #undef X_1000 #undef X10000 #define X____1(N) \ static const X Xs##N[] = {}; #define X___10(N) \ X____1(N##0) X____1(N##1) X____1(N##2) X____1(N##3) X____1(N##4) \ X____1(N##5) X____1(N##6) X____1(N##7) X____1(N##8) X____1(N##9) #define X__100(N) \ X___10(N##0) X___10(N##1) X___10(N##2) X___10(N##3) X___10(N##4) \ X___10(N##5) X___10(N##6) X___10(N##7) X___10(N##8) X___10(N##9) #define X_1000(N) \ X__100(N##0) X__100(N##1) X__100(N##2) X__100(N##3) X__100(N##4) \ X__100(N##5) X__100(N##6) X__100(N##7) X__100(N##8) X__100(N##9) #define X10000(N) \ X_1000(N##0) X_1000(N##1) X_1000(N##2) X_1000(N##3) X_1000(N##4) \ X_1000(N##5) X_1000(N##6) X_1000(N##7) X_1000(N##8) X_1000(N##9) X10000(0) #undef Z____1 #undef Z___10 #undef Z__100 #undef Z_1000 #undef Z10000 #define Z____1(N,I,J) \ Z(Xs##N,1,1), #define Z___10(N) \ Z____1(N##0,1,1) Z____1(N##0,1,1) \ Z____1(N##0,1,1) Z____1(N##1,2,1) \ Z____1(N##0,1,1) Z____1(N##2,1,2) \ Z____1(N##0,1,1) Z____1(N##3,6,3) \ Z____1(N##0,1,1) Z____1(N##4,7,2) \ Z____1(N##0,1,1) Z____1(N##5,1,3) \ Z____1(N##0,1,1) Z____1(N##6,5,9) \ Z____1(N##0,1,1) Z____1(N##7,7,1) \ Z____1(N##0,1,1) Z____1(N##8,3,3) \ Z____1(N##0,1,1) Z____1(N##9,2,2) #define Z__100(N) \ Z___10(N##0) Z___10(N##1) Z___10(N##2) Z___10(N##3) Z___10(N##4) \ Z___10(N##5) Z___10(N##6) Z___10(N##7) Z___10(N##8) Z___10(N##9) #define Z_1000(N) \ Z__100(N##0) Z__100(N##1) Z__100(N##2) Z__100(N##3) Z__100(N##4) \ Z__100(N##5) Z__100(N##6) Z__100(N##7) Z__100(N##8) Z__100(N##9) #define Z10000(N) \ Z_1000(N##0) // Z_1000(N##1) Z_1000(N##2) Z_1000(N##3) Z_1000(N##4) \ // Z_1000(N##5) Z_1000(N##6) Z_1000(N##7) Z_1000(N##8) Z_1000(N##9) static const X XsLast[] = {}; static const Z Zs[] = { Z10000(0) Z(XsLast,1,1) }; const Z* getzs() { return &Zs[0]; } ----- 8< ----- exploding in DSE: dead store elim1 : 45.34 (15%) usr 0.19 (28%) sys 45.53 (15%) wall 1016985 kB (45%) ggc ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/63191] [4.8/4.9/5/6 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC 2014-09-05 20:12 [Bug rtl-optimization/63191] New: 32-bit gcc uses excessive memory during dead store elimination with -fPIC woodfin at intersystems dot com ` (6 preceding siblings ...) 2015-04-07 21:39 ` steven at gcc dot gnu.org @ 2015-06-23 8:20 ` rguenth at gcc dot gnu.org 2015-06-26 19:57 ` [Bug rtl-optimization/63191] [4.9/5/6 " jakub at gcc dot gnu.org 2015-06-26 20:28 ` jakub at gcc dot gnu.org 9 siblings, 0 replies; 11+ messages in thread From: rguenth at gcc dot gnu.org @ 2015-06-23 8:20 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.8.5 |4.9.3 --- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3. ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/63191] [4.9/5/6 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC 2014-09-05 20:12 [Bug rtl-optimization/63191] New: 32-bit gcc uses excessive memory during dead store elimination with -fPIC woodfin at intersystems dot com ` (7 preceding siblings ...) 2015-06-23 8:20 ` [Bug rtl-optimization/63191] [4.8/4.9/5/6 " rguenth at gcc dot gnu.org @ 2015-06-26 19:57 ` jakub at gcc dot gnu.org 2015-06-26 20:28 ` jakub at gcc dot gnu.org 9 siblings, 0 replies; 11+ messages in thread From: jakub at gcc dot gnu.org @ 2015-06-26 19:57 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191 --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> --- GCC 4.9.3 has been released. ^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug rtl-optimization/63191] [4.9/5/6 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC 2014-09-05 20:12 [Bug rtl-optimization/63191] New: 32-bit gcc uses excessive memory during dead store elimination with -fPIC woodfin at intersystems dot com ` (8 preceding siblings ...) 2015-06-26 19:57 ` [Bug rtl-optimization/63191] [4.9/5/6 " jakub at gcc dot gnu.org @ 2015-06-26 20:28 ` jakub at gcc dot gnu.org 9 siblings, 0 replies; 11+ messages in thread From: jakub at gcc dot gnu.org @ 2015-06-26 20:28 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.9.3 |4.9.4 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-06-26 20:28 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-09-05 20:12 [Bug rtl-optimization/63191] New: 32-bit gcc uses excessive memory during dead store elimination with -fPIC woodfin at intersystems dot com 2014-09-08 9:01 ` [Bug rtl-optimization/63191] [4.8/4.9/5 Regression] " rguenth at gcc dot gnu.org 2014-11-24 13:18 ` rguenth at gcc dot gnu.org 2014-12-19 13:27 ` jakub at gcc dot gnu.org 2015-04-07 20:23 ` steven at gcc dot gnu.org 2015-04-07 20:42 ` woodfin at intersystems dot com 2015-04-07 21:30 ` steven at gcc dot gnu.org 2015-04-07 21:39 ` steven at gcc dot gnu.org 2015-06-23 8:20 ` [Bug rtl-optimization/63191] [4.8/4.9/5/6 " rguenth at gcc dot gnu.org 2015-06-26 19:57 ` [Bug rtl-optimization/63191] [4.9/5/6 " jakub at gcc dot gnu.org 2015-06-26 20:28 ` jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).