* [Bug c/37709] cc1: out of memory
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
@ 2008-10-01 23:43 ` regehr at cs dot utah dot edu
2008-10-01 23:49 ` [Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy pinskia at gcc dot gnu dot org
` (15 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: regehr at cs dot utah dot edu @ 2008-10-01 23:43 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
2008-10-01 23:43 ` [Bug c/37709] " regehr at cs dot utah dot edu
@ 2008-10-01 23:49 ` pinskia at gcc dot gnu dot org
2008-10-02 11:08 ` rguenth at gcc dot gnu dot org
` (14 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-10-01 23:49 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
2008-10-01 23:43 ` [Bug c/37709] " regehr at cs dot utah dot edu
2008-10-01 23:49 ` [Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy pinskia at gcc dot gnu dot org
@ 2008-10-02 11:08 ` rguenth at gcc dot gnu dot org
2008-10-02 12:57 ` rguenth at gcc dot gnu dot org
` (13 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-10-02 11:08 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
` (2 preceding siblings ...)
2008-10-02 11:08 ` rguenth at gcc dot gnu dot org
@ 2008-10-02 12:57 ` rguenth at gcc dot gnu dot org
2008-10-02 13:03 ` rguenth at gcc dot gnu dot org
` (12 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-10-02 12:57 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
` (3 preceding siblings ...)
2008-10-02 12:57 ` rguenth at gcc dot gnu dot org
@ 2008-10-02 13:03 ` rguenth at gcc dot gnu dot org
2008-10-02 14:28 ` jakub at gcc dot gnu dot org
` (11 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-10-02 13:03 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
` (4 preceding siblings ...)
2008-10-02 13:03 ` rguenth at gcc dot gnu dot org
@ 2008-10-02 14:28 ` jakub at gcc dot gnu dot org
2008-10-22 3:13 ` mmitchel at gcc dot gnu dot org
` (10 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu dot org @ 2008-10-02 14:28 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
` (5 preceding siblings ...)
2008-10-02 14:28 ` jakub at gcc dot gnu dot org
@ 2008-10-22 3:13 ` mmitchel at gcc dot gnu dot org
2008-11-11 20:11 ` hubicka at gcc dot gnu dot org
` (9 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2008-10-22 3:13 UTC (permalink / raw)
To: gcc-bugs
--
mmitchel at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37709
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
` (6 preceding siblings ...)
2008-10-22 3:13 ` mmitchel at gcc dot gnu dot org
@ 2008-11-11 20:11 ` hubicka at gcc dot gnu dot org
2008-11-22 17:35 ` steven at gcc dot gnu dot org
` (8 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: hubicka at gcc dot gnu dot org @ 2008-11-11 20:11 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
` (7 preceding siblings ...)
2008-11-11 20:11 ` hubicka at gcc dot gnu dot org
@ 2008-11-22 17:35 ` steven at gcc dot gnu dot org
2009-02-03 16:28 ` [Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info bonzini at gnu dot org
` (7 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: steven at gcc dot gnu dot org @ 2008-11-22 17:35 UTC (permalink / raw)
To: gcc-bugs
--
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
` (8 preceding siblings ...)
2008-11-22 17:35 ` steven at gcc dot gnu dot org
@ 2009-02-03 16:28 ` bonzini at gnu dot org
2009-02-04 7:04 ` bonzini at gnu dot org
` (6 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bonzini at gnu dot org @ 2009-02-03 16:28 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
` (9 preceding siblings ...)
2009-02-03 16:28 ` [Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info bonzini at gnu dot org
@ 2009-02-04 7:04 ` bonzini at gnu dot org
2009-02-12 10:29 ` hubicka at ucw dot cz
` (5 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: bonzini at gnu dot org @ 2009-02-04 7:04 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
` (10 preceding siblings ...)
2009-02-04 7:04 ` bonzini at gnu dot org
@ 2009-02-12 10:29 ` hubicka at ucw dot cz
2009-02-22 14:23 ` hubicka at gcc dot gnu dot org
` (4 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: hubicka at ucw dot cz @ 2009-02-12 10:29 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
` (11 preceding siblings ...)
2009-02-12 10:29 ` hubicka at ucw dot cz
@ 2009-02-22 14:23 ` hubicka at gcc dot gnu dot org
2009-02-22 14:23 ` hubicka at gcc dot gnu dot org
` (3 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: hubicka at gcc dot gnu dot org @ 2009-02-22 14:23 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
` (12 preceding siblings ...)
2009-02-22 14:23 ` hubicka at gcc dot gnu dot org
@ 2009-02-22 14:23 ` hubicka at gcc dot gnu dot org
2009-02-22 14:46 ` hubicka at gcc dot gnu dot org
` (2 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: hubicka at gcc dot gnu dot org @ 2009-02-22 14:23 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
` (13 preceding siblings ...)
2009-02-22 14:23 ` hubicka at gcc dot gnu dot org
@ 2009-02-22 14:46 ` hubicka at gcc dot gnu dot org
2009-02-23 13:11 ` hubicka at gcc dot gnu dot org
2009-02-23 13:12 ` hubicka at gcc dot gnu dot org
16 siblings, 0 replies; 18+ messages in thread
From: hubicka at gcc dot gnu dot org @ 2009-02-22 14:46 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
` (14 preceding siblings ...)
2009-02-22 14:46 ` hubicka at gcc dot gnu dot org
@ 2009-02-23 13:11 ` hubicka at gcc dot gnu dot org
2009-02-23 13:12 ` hubicka at gcc dot gnu dot org
16 siblings, 0 replies; 18+ messages in thread
From: hubicka at gcc dot gnu dot org @ 2009-02-23 13:11 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info
2008-10-01 23:42 [Bug c/37709] New: cc1: out of memory regehr at cs dot utah dot edu
` (15 preceding siblings ...)
2009-02-23 13:11 ` hubicka at gcc dot gnu dot org
@ 2009-02-23 13:12 ` hubicka at gcc dot gnu dot org
16 siblings, 0 replies; 18+ messages in thread
From: hubicka at gcc dot gnu dot org @ 2009-02-23 13:12 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread