[Bug rtl-optimization/63191] New: 32-bit gcc uses excessive memory during dead store elimination with -fPIC

[Bug rtl-optimization/63191] New: 32-bit gcc uses excessive memory during dead store elimination with -fPIC

[woodfin at intersystems dot com]

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)

[Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC

[rguenth at gcc dot gnu.org]

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.

[Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC

[rguenth at gcc dot gnu.org]

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

[Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC

[jakub at gcc dot gnu.org]

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.

[Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC

[steven at gcc dot gnu.org]

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 ;-)

[Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC

[woodfin at intersystems dot com]

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.

[Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC

[steven at gcc dot gnu.org]

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...

[Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC

[steven at gcc dot gnu.org]

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

[Bug rtl-optimization/63191] [4.8/4.9/5/6 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC

[rguenth at gcc dot gnu.org]

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.

[Bug rtl-optimization/63191] [4.9/5/6 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC

[jakub at gcc dot gnu.org]

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.

[Bug rtl-optimization/63191] [4.9/5/6 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC

[jakub at gcc dot gnu.org]

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