[Bug c/37709] New: cc1: out of memory

[Bug c/37709] New: cc1: out of memory

[regehr at cs dot utah dot edu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

I don't know how much memory gcc is "supposed" to use but this seems
disproportionate. 

Seen on r140777 on Ubuntu Hardy.

Obviously the testcase itself is meaningless, but it is supposed to be free of
undefined behavior.  Before CPP it was about 37 kB.

regehr@john-home:~/volatile/tmp43$ current-gcc -Os -g foo.c
small2.c: In function ‘func_41’:
small2.c:309: warning: large integer implicitly truncated to unsigned type

cc1: out of memory allocating 268435456 bytes after a total of 29876224 bytes
regehr@john-home:~/volatile/tmp43$ current-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --program-prefix=current-
--enable-languages=c,c++ --prefix=/home/regehr
Thread model: posix
gcc version 4.4.0 20080930 (experimental) (GCC)


-- 
           Summary: cc1: out of memory
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: regehr at cs dot utah dot edu
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/37709] cc1: out of memory

[regehr at cs dot utah dot edu]

------- Comment #1 from regehr at cs dot utah dot edu  2008-10-01 23:42 -------
Created an attachment (id=16448)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16448&action=view)
failure-inducing input


-- 


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

[Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2008-10-01 23:48 -------
The inlininer is going crazy some how.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu dot
                   |                            |org
          Component|c                           |tree-optimization
           Keywords|                            |compile-time-hog, memory-hog
            Summary|cc1: out of memory          |[4.4 Regression] inliner
                   |                            |gone crazy
   Target Milestone|---                         |4.4.0


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

[Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2008-10-02 11:06 -------
We seem to accumulate an awful huge stack of BLOCKs during inlining ... are
BLOCKs shared?  Maybe we can avoid copying equivalent ones.

This testcase is bad, as in the end we will optimize it all away to a constant
(possibly - it didn't finish for me either ...).


-- 


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

[Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2008-10-02 12:56 -------
      /* When we are not doing full debug info, we however can keep around
         only the used variables for cfgexpand's memory packing saving quite
         a lot of memory.  */
      else if (debug_info_level == DINFO_LEVEL_NORMAL
               || debug_info_level == DINFO_LEVEL_VERBOSE
               /* Removing declarations before inlining is going to affect
                  DECL_UID that in turn is going to affect hashtables and
                  code generation.  */
               || !cfun->after_inlining)
        unused = false;

the last check makes us blow up for -g0, otherwise we blow up because we
retain dead variables for debugging purposes.


-- 


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

[Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2008-10-02 13:02 -------
We optimize func_1 to

func_1:
        movw    g_290(%rip), %ax
        movl    $0, g_3(%rip)
        cwtl
        ret

inlining all its callees recursively ...


-- 


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

[Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy

[jakub at gcc dot gnu dot org]

------- Comment #6 from jakub at gcc dot gnu dot org  2008-10-02 14:26 -------
The difference is mainly that HEAD inlines all func_* calls, while 4.3 keeps
many of them around (I see 30 call func_* insns in 4.3).  The 4.4 .text is
about half the size of 4.3 .text (i.e. inliner did much better job), but the
emitted
.debug_info is in 4.4 13MB compared to 12KB in 4.3 generated code.
You need 7GB of RAM to compile this successfully.

In theory, by using a more compact representation of BLOCK nodes we could store
them in ~ 13MB (as that's how it is possible to encode it in DWARF3).


-- 


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

[Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


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

[Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy

[hubicka at gcc dot gnu dot org]

------- Comment #7 from hubicka at gcc dot gnu dot org  2008-11-11 20:09 -------
Current implementation of inliner is perfectly unaware of the debug info size
implications. There is alternative to limit number of BLOCKS in function body
growth same way as we limit stack usage that would just add little extra
bookkeeping, but I would like to be sure that there is no better alternative
first.  Current BLOCK removal code is quite conservative based on my
observations of what RTL code did originally, perhaps we can be more strict?


-- 


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

[Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy

[steven at gcc dot gnu dot org]

-- 

steven 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         |2008-11-22 17:34:27
               date|                            |


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

[Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info

[bonzini at gnu dot org]

------- Comment #8 from bonzini at gnu dot org  2009-02-03 16:28 -------
changing summary, inlining _is_ the right thing to do.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.4 Regression] inliner    |[4.4 Regression] inlining
                   |gone crazy                  |causes explosion in debug
                   |                            |info


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

[Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info

[bonzini at gnu dot org]

------- Comment #9 from bonzini at gnu dot org  2009-02-04 07:04 -------
sizeof (tree_block) is 52 bytes on 32-bit hosts.  Of these, 8 are unused (ann
and type), 8 are frequently unused (block_fragment stuff -- always write-only
at debug level 0).  Moving fragments into an annotation and reusing type for
something would already save 20% of the memory.

I think we need a better representation for blocks after parsing.  Maybe
gimplification unit-at-a-time will make this easier, I don't know.


-- 


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

[Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info

[hubicka at ucw dot cz]

------- Comment #10 from hubicka at ucw dot cz  2009-02-12 10:28 -------
Subject: Re:  [4.4 Regression] inlining causes explosion in debug info

> sizeof (tree_block) is 52 bytes on 32-bit hosts.  Of these, 8 are unused (ann
> and type), 8 are frequently unused (block_fragment stuff -- always write-only
> at debug level 0).  Moving fragments into an annotation and reusing type for
> something would already save 20% of the memory.

I was looking into the bug last month but then got distracted by other
more urgent things.  I guess it is time to get back ;)

Even if our blocks representation is not the most effecient around, I
think main problem is that we keep too many blocks around that never get
it to debug info or are never serving useful purpose.  The testcase
compiled at -g3 needs about 100MB of DWARF section and before inlining
we unfortunately need to keep debug info at -g3 verbosity.  I plan to
look into what blocks gets ignored by the dwarf2out but also it would be
great to figure out if we really need them in debug info at first place.
(for example for every inlined function we create container block and
then block containing the arguments.  Current tree-ssa-live code to
prune out blocks preserves both)

Honza


-- 


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

[Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info

[hubicka at gcc dot gnu dot org]

------- Comment #11 from hubicka at gcc dot gnu dot org  2009-02-22 14:22 -------
Created an attachment (id=17340)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17340&action=view)
Dump of block structure


-- 


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

[Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info

[hubicka at gcc dot gnu dot org]

------- Comment #12 from hubicka at gcc dot gnu dot org  2009-02-22 14:23 -------
Created an attachment (id=17341)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17341&action=view)
Little dumping facility


-- 


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

[Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info

[hubicka at gcc dot gnu dot org]

------- Comment #13 from hubicka at gcc dot gnu dot org  2009-02-22 14:46 -------
There are obviously giant trees of blocks that have all variables unused and no
statements in them coming from the early inliner.  I am getting convinced we
can safely prune those even at -g3: user can not breakpoint into the block in
any way and can't ask for the value....

So I guess we could be at -g eliminating inner blocks with no used variables
and no statements just keeping around blocks with statements including the
unused vars so we can get proper "optimized out" debugger info.

I will prepare patch for this.

Honza


-- 


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

[Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info

[hubicka at gcc dot gnu dot org]

------- Comment #14 from hubicka at gcc dot gnu dot org  2009-02-23 13:11 -------
Subject: Bug 37709

Author: hubicka
Date: Mon Feb 23 13:10:53 2009
New Revision: 144381

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144381
Log:
        PR tree-optimization/37709                                              
        * tree.c (block_ultimate_origin): Move here from dwarf2out.             
        * tree.h (block_ultimate_origin): Declare.                              
        * dwarf2out.c (block_ultimate_origin): Move to tree.c                   
        * tree-ssa-live.c (remove_unused_scope_block_p):
        Eliminate blocks containig no instructions nor live variables nor
        nested blocks.
        (dump_scope_block): New function.
        (remove_unused_locals): Enable removal of dead blocks by default;
        enable dumping at TDF_DETAILS.                                          

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dbxout.c
    trunk/gcc/dwarf2out.c
    trunk/gcc/tree-ssa-live.c
    trunk/gcc/tree.c
    trunk/gcc/tree.h


-- 


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

[Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info

[hubicka at gcc dot gnu dot org]

------- Comment #15 from hubicka at gcc dot gnu dot org  2009-02-23 13:12 -------
Fixed.


-- 

hubicka at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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