[Bug middle-end/41343] New: sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

When compiling the attached file as:

powerpc-linux-gnu-gcc dosincos.i -g -O2 -std=gnu99 -fgnu89-inline
-fmerge-all-constants

The memory use of GCC balloons to 4GB+.  I have a low ulimit on my machine, so
I don't know whether leaving it alone with more memory would let the
compilation finish.  Using -fdump-tree-all-details indicates that things die
somewhere in the inline_param3 pass.

Discussion on IRC demonstrates the same behavior with a cross compiler from
x86-64, with memory usage up to 12GB without finishing.


--
           Summary: sysdeps/ieee754/dbl-64/dosincos.c from glibc causes
                    excessive memory use
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: froydnj at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #1 from froydnj at gcc dot gnu dot org  2009-09-12 04:05 -------
Created an attachment (id=18571)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18571&action=view)
testcase


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #2 from aoliva at gcc dot gnu dot org  2009-09-12 06:39 -------
Created an attachment (id=18572)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18572&action=view)
patch that might help alleviate the problem

This patch helped me save a lot of memory on another PPC testcase that involved
lots of expressions with equivalent values, which causes “interesting“ behavior
in var-tracking/cselib, generating a lot of RTL junk.  From your description,
it's not clear that it's the same problem, but I thought I'd post the
(unpolished) patch anyway, because a proper algorithmic fix to var-tracking
will take longer.  Even more so because I'm away for a week, starting today.  I
hope this helps.  Please let me know.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #3 from ramana at gcc dot gnu dot org  2009-09-12 06:48 -------
*** Bug 41342 has been marked as a duplicate of this bug. ***


--

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ramana at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #4 from ramana at gcc dot gnu dot org  2009-09-12 06:49 -------
This test case fails for an arm-linux-gnueabi target as well.


--

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 GCC target triplet|powerpc-linux-gnu           |powerpc-linux-gnu, arm-
                   |                            |linux-gnueabi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #5 from ramana at gcc dot gnu dot org  2009-09-12 07:05 -------
(In reply to comment #2)
> Created an attachment (id=18572)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18572&action=view) [edit]

> patch that might help alleviate the problem
>
> This patch helped me save a lot of memory on another PPC testcase that involved
> lots of expressions with equivalent values, which causes “interesting“ behavior
> in var-tracking/cselib, generating a lot of RTL junk.  From your description,
> it's not clear that it's the same problem, but I thought I'd post the
> (unpolished) patch anyway, because a proper algorithmic fix to var-tracking
> will take longer.  Even more so because I'm away for a week, starting today.  I
> hope this helps.  Please let me know.
>

The patch didn't apply cleanly for me and didn't make any noticeable difference
on arm-*eabi configuratons for me.


--

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-09-12 07:05:26
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #6 from rguenth at gcc dot gnu dot org  2009-09-12 11:56 -------
We should definitely limit the size of expressions we store in debug
stmts/insns.


--

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |memory-hog
            Summary|sysdeps/ieee754/dbl-        |[4.5 Regression]
                   |64/dosincos.c from glibc    |sysdeps/ieee754/dbl-
                   |causes excessive memory use |64/dosincos.c from glibc
                   |                            |causes excessive memory use
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #7 from rguenth at gcc dot gnu dot org  2009-09-12 12:10 -------
Because I can easily cause exponential growth with them:

void foo (int i)
{
  int i1 = i + i;
  int i2 = i1 + i1;
  int i3 = i2 + i2;
  int i4 = i3 + i3;
}

will generate

  # DEBUG i1 => i_1(D) + i_1(D)
  # DEBUG i2 => (i_1(D) + i_1(D)) + (i_1(D) + i_1(D))
  # DEBUG i3 => ((i_1(D) + i_1(D)) + (i_1(D) + i_1(D))) + ((i_1(D) + i_1(D)) +
(i_1(D) + i_1(D)))
  # DEBUG i4 => (((i_1(D) + i_1(D)) + (i_1(D) + i_1(D))) + ((i_1(D) + i_1(D)) +
(i_1(D) + i_1(D)))) + (((i_1(D) + i_1(D)) + (i_1(D) + i_1(D))) + ((i_1(D) +
i_1(D)) + (i_1(D) + i_1(D))))

Testcase:

#define X(new,old) int i ## new = i ## old + i ## old;
#define Y(pfx) X(pfx ## 1, pfx) \
  X(pfx ## 2, pfx ## 1) \
  X(pfx ## 3, pfx ## 2) \
  X(pfx ## 4, pfx ## 3) \
  X(pfx ## 5, pfx ## 4) \
  X(pfx ## 6, pfx ## 5) \
  X(pfx ## 7, pfx ## 6) \
  X(pfx ## 8, pfx ## 7) \
  X(pfx ## 9, pfx ## 8)

void foo (int i1)
{
  Y(1)
  Y(11)
  Y(111)
}


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #8 from rguenth at gcc dot gnu dot org  2009-09-12 12:11 -------
We should be able to refer to previous debug insn/stmt vars instead of blindly
propagating all RHSs.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #9 from jakub at gcc dot gnu dot org  2009-09-14 15:04 -------
Limiting the size of the debug_stmt/debug_insn expression is certainly
desirable, having it unbounded is bad.  The question is what to do if the size
grows too much.  One possibility is dropping them to the floor, another one
would be to have a way to refer to other vars that are already tracked at the
current spot.  In debug info we could use DW_OP_call{2,4} to refer to those
DIEs' DW_AT_location, but AFAIK gdb doesn't handle those 2 yet.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #10 from rguenth at gcc dot gnu dot org  2009-09-14 16:13 -------
The simplest thing may be to disallow extra propagations, like from

 D.1234_2 = i0_1 + i0_1;
 # DEBUG i1 => D.1234_2

to

 # DEBUG i1 => i0 + i0

where dropping from i0_1 to i0 if more propagations would cause extra growth
and i0 is a user variable.

Of course a little more fancy.  In fact always stopping the propagation
if we get a user var should work as well as we'd have a proper debug
stmt for them anyway.  No?


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #11 from aoliva at gcc dot gnu dot org  2009-09-15 04:17 -------
Referencing plain variable names in debug stmts is probably not a good idea, I
think it's too fragile.  However, arranging for SSA defs that would have been
propagated into debug stmts to be instead replaced with other debug stmts that
bind to “temps” appears to be pretty easy to introduce.  I'm (slowly, on the
road) working on a patch to do just that.

So instead of

# DEBUG i2 => ((i_1(D) + i_1(D)) + (i_1(D) + i_1(D))

we'll have

# DEBUG DT.0 => (i_1(D) + i_1(D))
# DEBUG i2 => DT.0 + DT.0

these debug temps, if introduced as a different kind of “declaration”, with its
own uid counter, won't interfere with regular declarations UIDs, which affect
codegen.  They can be expanded and linked to a new RTL form, that links back to
the tree form, so that the new RTL form can be used in RTL expressions, while
the VAR_LOCATION still holds the tree form, and then var-tracking generates a
value for the RTL expression, and voila :-)

The only case of loss of debug info I can think of is if the block containing a
debug bind stmt for one of these temps is removed, but a subsequent block that
would require the debug bind stmt isn't.  I don't think this should happen in
general (it would be non-SSA), but I haven't quite thought it through.  We'll
see...


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #12 from rguenth at gcc dot gnu dot org  2009-09-15 09:02 -------
Why do you think refering to other debug stmts decl is not a good idea?  I
was thinking of simplifying propagation into debug stmts by simply replacing
all uses of a to-become dead SSA name with a non-artificial decl with its
underlying declaration.  So,

 i_1 = j_2 + k_3;
 # DEBUG i <= i_1
 # DEBUG foo <= i_1 + 1

on removing i_1 becomes

 # DEBUG i <= j_1 + k_3
 # DEBUG foo <= i + 1

based on the fact that we better had a debug stmt for i already.

In fact I can't see how this is different from what you propose.  And in
fact your proposal effectively would do

 # DEBUG tmp0 <= j_1 + k_3
 # DEBUG i <= tmp0
 # DEBUG foo <= tmp0 + 1

effectively adding a new debug stmt for each regular stmt you remove.

I don't think that's going to fly.


--

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #13 from jakub at gcc dot gnu dot org  2009-09-15 09:18 -------
For dwarf2out.c, it is IMHO desirable to be able to find out the original decls
which you refer to, rather than have some artificial ones.  Otherwise for
DW_OP_call{2,4} you'd have to create artificial variables in the debug info and
refer to them.  dwarf2out.c then can decide whether the location is simple
enough to inline its location expression, or is too complex and use
DW_OP_call{2,4} in that case.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

--

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #14 from jakub at gcc dot gnu dot org  2009-09-22 12:13 -------
Correction - artificial variables aren't needed, DW_TAG_dwarf_procedure with
just DW_AT_location with the expression or loclist is enough.
That's BTW something that a dwarf compactor could do - look at dwarf
expressions in DW_AT_location attributes and .debug_loc, see if there are
subexpressions that occur frequently and big enough that replacing them with 3
byte DW_OP_call2 <ref2> would be worthwhile, for those add
DW_TAG_dwarf_procedure at some low DIE offset (< 64KB into .debug_info).  GCC
could do that too of course, perhaps as a special pass over the debug info
before sizing it.


--

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roland at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

--

aoliva at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |aoliva at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
          Component|middle-end                  |debug


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #15 from aoliva at gcc dot gnu dot org  2009-09-22 19:03 -------
(In reply to comment #12)
> Why do you think refering to other debug stmts decl is not a good idea?

Because referring to decls already has a well-defined meaning in debug stmts,
and that meaning refers to a run-time value/location arbitrarily assigned the
name of the variable, rather than to the source-level value of the variable.
These values may very well be different, especially if optimizations coalesced
multiple variables into a single run-time location, and we move the references
across modifications of the run-time location.

This would get very messy in RTL, although it may not be immediately apparent
in gimple, and it might even appear to work for trivial cases.  But once the
ambiguity hits, you lose.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #16 from matz at gcc dot gnu dot org  2009-10-03 23:18 -------
Created an attachment (id=18700)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18700&action=view)
pr41264-test.c

Hmm, seems I used the wrong bug report to assign a nicer testcase.  Here
the comment and testcase I initially added to PR41264:
---
Found a nice testcase for exponential explosion.  It's reduced from tree.c
(make_vector_type) when building with -fprofile-generate.  The testcase needs
simply "-O2 -g" and takes a ridiculous amount of > 4GB RAM.
It's the tree-ssa-sink pass that triggers this in this case (with slight
variations in the testcase I can also make it blow up in RTL fwprop).

This means btw. that profiledbootstrap is broken.
---
Compile this with
% ./cc1 -O2 -g pr41264-test.c
and cry.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343

------- Comment #17 from aoliva at gcc dot gnu dot org  2009-10-06 04:38 -------
This patch fixes the problem:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00112.html


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343