[Bug c++/39077] New: GCSE-optimization causes enormous binary size increase (~20 times !)

[Bug c++/39077] New: GCSE-optimization causes enormous binary size increase (~20 times !)

[comer352l at googlemail dot com]

The example attached is a simple data-container-class. The data is stored as
Qt4-QStringLists.
Everything was fine with gcc 4.1 (330KB). 4.2 already caused a significant
increase. With 4.3, the binary size increased enormously again (6.7MB !).

When I disable GCSE-optimization using the additional flag "-fnogcse", I get
normal binary sizes (360KB with 4.3.2).


Command line use for compilation:
g++ -c -pipe -O2 -march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -g -Wall -W -D_REENTRANT -DQT_NO_DEBUG
-DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/default -I.
-I/usr/include/QtCore -I/usr/include/QtCore -I/usr/include/QtGui
-I/usr/include/QtGui -I/usr/include -I. -Isrc -Isrc/linux -I. -I. -o
SSMprotocol_def_en.o src/SSMprotocol_def_en.cpp

=> no errors or warnings


GCC-info (Output of 'g++ -v'):

Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --without-system-libunwind --with-cpu=generic
--build=i586-suse-linux
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)


-- 
           Summary: GCSE-optimization causes enormous binary size increase
                    (~20 times !)
           Product: gcc
           Version: 4.3.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: comer352l at googlemail dot com


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

[Bug c++/39077] GCSE-optimization causes enormous binary size increase (~20 times !)

[comer352l at googlemail dot com]

------- Comment #1 from comer352l at googlemail dot com  2009-02-02 16:22 -------
Created an attachment (id=17229)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17229&action=view)
Preprocessed file (created with gcc4.3.2)


-- 


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

[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2009-02-03 09:55 -------
Created an attachment (id=17230)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17230&action=view)
unincluded testcase


-- 


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

[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2009-02-03 09:54 -------
Confirmed.  Likely triggered by inliner decision changes.  -Os is fine. 
Steven,
do we need to constrain GCSE similar to your PRE patches?  Is this PPRE in GCSE
at work?

Object size with G++ 4.4 is 7MB.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stevenb dot gcc at gmail dot
                   |                            |com
             Status|UNCONFIRMED                 |NEW
          Component|c++                         |rtl-optimization
     Ever Confirmed|0                           |1
           Keywords|                            |missed-optimization
      Known to fail|                            |4.3.3 4.4.0
      Known to work|                            |4.2.4
   Last reconfirmed|0000-00-00 00:00:00         |2009-02-03 09:54:50
               date|                            |
            Summary|GCSE-optimization causes    |[4.3/4.4 Regression] GCSE-
                   |enormous binary size        |optimization causes enormous
                   |increase (~20 times !)      |binary size increase (~20
                   |                            |times !)
   Target Milestone|---                         |4.3.4


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

[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[steven at gcc dot gnu dot org]

------- Comment #4 from steven at gcc dot gnu dot org  2009-02-05 14:23 -------
Investigating...


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2009-02-03 09:54:50         |2009-02-05 14:23:43
               date|                            |


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

[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[steven at gcc dot gnu dot org]

------- Comment #5 from steven at gcc dot gnu dot org  2009-02-06 11:59 -------
I am unable to reproduce this on Cygwin.  Anyone got a .gcse dump for me?


-- 


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

[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2009-02-06 13:07 -------
It's at 280MB and still growing.  Let's hope it compresses well ;)


-- 


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

[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2009-02-06 14:35 -------
Ok, still too large to attach.  It should appear at
http://gcc.opensuse.org/SSMprotocol_def_en.cpp.140r.gcse1.lzma
after some time.


-- 


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

[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[steven at gcc dot gnu dot org]

------- Comment #8 from steven at gcc dot gnu dot org  2009-02-06 17:50 -------
Re. comment #2:
This looks more like normal PRE over exception edges, which AFAIK tree-ssa-pre
does not do (it keeps ANTIC_IN empty for any block that has abnormal
predecessors).


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|steven at gcc dot gnu dot   |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[steven at gcc dot gnu dot org]

------- Comment #9 from steven at gcc dot gnu dot org  2009-02-21 15:25 -------
It looks like this is some kind of quadratic insertion problem, maybe PPRE
after all.  I hacked GCSE a bit to see what is going on.

I fist counted the number basic blocks and edges per function, the number of
expressions considered by PRE, and the block with the largest number of
predecessor edges.  Then, I counted for each partially redundant expression how
many inserts are necessary to make the expression fully redundant. Here are the
numbers of the two largest functions:

counting (nbb = 9189 ; nedges = 15477 ; nexpr = 2417 ; max(preds) = 583)
1164, 1162, 1160, 1158, 1156, 1154, 1152, 1150, 1148, 1146, 

counting (nbb = 5834 ; nedges = 9727 ; nexpr = 1936 ; max(preds) = 489)
976, 974, 972, 970, 968, 966, 964, 962, 960, 958, 

See how there is a series there?

1164 = 2*583 = 2*max(preds) for the first function, and from thereon, we have a
series of n(i+1) = n(i) - 2.  This goes on for a long time (I've only included
the top 10 partially redundant expressions in the above numbers).

Likewise for the second function: 976 = 2*489 etc.

This *is* the same behavior as what we see with PPRE in tree-ssa-pre.c.  But I
don't understand enough of what is going on to be sure that this is PPRE in
gcse.c.


-- 

steven at gcc dot gnu dot org changed:

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


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

[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[steven at gcc dot gnu dot org]

------- Comment #10 from steven at gcc dot gnu dot org  2009-02-21 16:09 -------
OK, I checked what we're PREing here.  This is indeed partial-partial PRE.

I suppose something like the following is a good idea.  I'll admit it's
brute-force, but I'm not sure how else to stop GCSE-PRE from doing this (it's
baked into the LCM equations).

Jeff, what do you think about this PR?

Index: gcse.c
===================================================================
--- gcse.c      (revision 144303)
+++ gcse.c      (working copy)
@@ -3801,16 +3801,30 @@
       edge e;
       edge_iterator ei;

-      /* If the current block is the destination of an abnormal edge, we
-        kill all trapping expressions because we won't be able to properly
-        place the instruction on the edge.  So make them neither
-        anticipatable nor transparent.  This is fairly conservative.  */
-      FOR_EACH_EDGE (e, ei, bb->preds)
-       if (e->flags & EDGE_ABNORMAL)
-         {
-           sbitmap_difference (antloc[bb->index], antloc[bb->index],
trapping_expr);
-           sbitmap_difference (transp[bb->index], transp[bb->index],
trapping_expr);
-           break;
+      if (EDGE_COUNT (bb->preds) > 20) /* ??? Should be a PARAM */
+       {
+         /* If a block has a large number of incoming edges, then inserting
+            many expressions in the predecessors to make one/few expression
+            fully redundant is probably not a profitable transformation.
+            Make all expressions non-anticipatable and non-transparent.  */
+         sbitmap_zero (antloc[bb->index]);
+         sbitmap_zero (transp[bb->index]);
+       }
+      else
+       {
+         /* If the current block is the destination of an abnormal edge, we
+            kill all trapping expressions because we won't be able to properly
+            place the instruction on the edge.  So make them neither
+            anticipatable nor transparent.  This is fairly conservative.  */
+         FOR_EACH_EDGE (e, ei, bb->preds)
+           if (e->flags & EDGE_ABNORMAL)
+             {
+               sbitmap_difference (antloc[bb->index],
+                                   antloc[bb->index], trapping_expr);
+               sbitmap_difference (transp[bb->index],
+                                   transp[bb->index], trapping_expr);
+               break;
+             }
          }

       sbitmap_a_or_b (ae_kill[bb->index], transp[bb->index], comp[bb->index]);


-- 

steven at gcc dot gnu dot org changed:

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


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

[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[bonzini at gnu dot org]

------- Comment #11 from bonzini at gnu dot org  2009-02-26 09:12 -------
I remember seeing this kind of insertion in very old GCCs too (inserting all
sort of loads at the end of every branch of a switch statement).  I like
Steven's patch, even though it's a bit brute force.


-- 


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

[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[law at redhat dot com]

------- Comment #12 from law at redhat dot com  2009-02-26 16:53 -------
Subject: Re:  [4.3/4.4 Regression] GCSE-optimization
 causes enormous binary size increase (~20 times !)

steven at gcc dot gnu dot org wrote:
> ------- Comment #10 from steven at gcc dot gnu dot org  2009-02-21 16:09 -------
> OK, I checked what we're PREing here.  This is indeed partial-partial PRE.
>
> I suppose something like the following is a good idea.  I'll admit it's
> brute-force, but I'm not sure how else to stop GCSE-PRE from doing this (it's
> baked into the LCM equations).
>
> Jeff, what do you think about this PR?
>   
It's overkill, but overkill I can live with -- it'd be marginally better 
if we waited until we were sure that insertion on those edges was needed 
rather than just blindly forgetting everything we know about these 
blocks with a high in-degree.

It'd also be marginally better if we had a better metric than just 
in-degree -- specifically if we had some idea of how many redundancies 
get eliminated.   This would be a nice future enhancement.

I'll OK this after turning the in-degree check to use a PARAM.

Jeff


-- 


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

[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2009-02-05 14:23:43         |2009-03-08 21:38:43
               date|                            |


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

[Bug rtl-optimization/39077] [4.3/4.4/4.5 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[steven at gcc dot gnu dot org]

------- Comment #13 from steven at gcc dot gnu dot org  2009-04-12 23:46 -------
The real bug is that somehow MEM_ATTRS are not shared anymore.  We have lots
and lots of exactly the same expression in the table, e.g.:

Index 3 (hash value 4232)
  (mem/s/f/c:SI (plus:SI (reg/f:SI 20 frame)
        (const_int -3828 [0xfffffffffffff10c])) [32 cpy.d+0 S4 A32])
Index 6 (hash value 4232)
  (mem/s/f/c:SI (plus:SI (reg/f:SI 20 frame)
        (const_int -3828 [0xfffffffffffff10c])) [32 cpy.d+0 S4 A32])
Index 10 (hash value 4232)
  (mem/s/f/c:SI (plus:SI (reg/f:SI 20 frame)
        (const_int -3828 [0xfffffffffffff10c])) [32 cpy.d+0 S4 A32])


but exp_equiv_p() thinks these are not equivalent, because the MEM_ATTRS
pointers are not the same.  We should have MEM_ATTRS(x)==MEM_ATTRS(y) for two
MEMs with the same memory attributes, but here the pointers are not the same. 
So we're allocating MEM_ATTRS somewhere without going via the table, or we're
adjusting MEM_ATTRS somewhere wvia an incorrect interface.


-- 


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

[Bug rtl-optimization/39077] [4.3/4.4/4.5 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[steven at gcc dot gnu dot org]

------- Comment #14 from steven at gcc dot gnu dot org  2009-04-12 23:52 -------
Ah, how subtle.

(gdb) p MEM_ATTRS(x)
$25 = (mem_attrs *) 0x7f20d1ad0440
(gdb) p MEM_ATTRS(y)
$26 = (mem_attrs *) 0x7f20d1ad71a0
(gdb) p MEM_ATTRS(*x)
$27 = (mem_attrs *) 0x7f20d1ad0440
(gdb) p MEM_ATTRS(*y)
$28 = (mem_attrs *) 0x7f20d1ad71a0
(gdb) p MEM_ATTRS(x)
$29 = (mem_attrs *) 0x7f20d1ad0440
(gdb) p MEM_ATTRS(y)
$30 = (mem_attrs *) 0x7f20d1ad71a0
(gdb) p *MEM_ATTRS(x)
$31 = {expr = 0x7f20d406cfa0, offset = 0x7f20d9e05450, size = 0x7f20d9e05490,
alias = 32, 
  align = 32}
(gdb) p *MEM_ATTRS(y)
$32 = {expr = 0x7f20d4093190, offset = 0x7f20d9e05450, size = 0x7f20d9e05490,
alias = 32, 
  align = 32}
(gdb) p debug_tree(MEM_ATTRS(x)->expr)
 <component_ref 0x7f20d406cfa0
    type <pointer_type 0x7f20d6bd96c0
        type <record_type 0x7f20d6bd8d80 Data type_5 BLK
            size <integer_cst 0x7f20d7fd4510 constant 160>
            unit size <integer_cst 0x7f20d7fd44b0 constant 20>
            align 32 symtab 0 alias set 87 canonical type 0x7f20d6bd8d80 fields
<field_decl 0x7f20d6b58640 ref> context <record_type 0x7f20d7710840 QString>
            full-name "struct QString::Data"
            X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
            pointer_to_this <pointer_type 0x7f20d6bd96c0> chain <type_decl
0x7f20d6bd8e40 Data>>
        sizes-gimplified unsigned SI
        size <integer_cst 0x7f20d9e00a50 constant 32>
        unit size <integer_cst 0x7f20d9e006c0 constant 4>
        align 32 symtab 0 alias set 32 canonical type 0x7f20d6bd96c0
        pointer_to_this <pointer_type 0x7f20d6a15d80> reference_to_this
<reference_type 0x7f20d6be3a80>>

    arg 0 <var_decl 0x7f20d4073be0 cpy
        type <record_type 0x7f20d74f5b40 QString readonly sizes-gimplified
addressable needs-constructing type_1 type_4 type_5 type_6 BLK size
<integer_cst 0x7f20d9e00a50 32> unit size <integer_cst 0x7f20d9e006c0 4>
            align 32 symtab 0 alias set -1 canonical type 0x7f20d74f5b40
            attributes <tree_list 0x7f20d6b64b10
                purpose <identifier_node 0x7f20d7fd2f00 visibility
                bindings <(nil)>
                local bindings <(nil)>>
                value <tree_list 0x7f20d6b64ae0
                    value <string_cst 0x7f20d6b64ab0 type <array_type
0x7f20d7710b40>
                        readonly constant static "default\000">>> fields
<const_decl 0x7f20d6b57280 SectionDefault>
            full-name "const class QString"
            needs-constructor needs-destructor X() X(constX&) this=(X&)
n_parents=0 use_template=0 interface-unknown
            pointer_to_this <pointer_type 0x7f20d6b68f00> reference_to_this
<reference_type 0x7f20d74f5c00>>
        addressable used tree_1 tree_2 tree_3 in_system_header decl_1 decl_5
BLK file /usr/include/QtCore/qlist.h line 420 col 21 size <integer_cst
0x7f20d9e00a50 32> unit size <integer_cst 0x7f20d9e006c0 4>
        align 32 context <function_decl 0x7f20d5f90800 __comp_ctor >
abstract_origin <var_decl 0x7f20d5553be0 cpy>
        (mem/s/c:BLK (plus:SI (reg/f:SI 20 frame)
        (const_int -3828 [0xfffffffffffff10c])) [31 cpy+0 S4 A32])>
    arg 1 <field_decl 0x7f20d6b58e60 d type <pointer_type 0x7f20d6bd96c0>
        used private unsigned nonlocal decl_3 SI file
/usr/include/QtCore/qstring.h line 574 col 11 size <integer_cst 0x7f20d9e00a50
32> unit size <integer_cst 0x7f20d9e006c0 4>
        align 32 offset_align 128
        offset <integer_cst 0x7f20d9e006f0 constant 0>
        bit offset <integer_cst 0x7f20d9e232d0 constant 0> context <record_type
0x7f20d7710840 QString>
        chain <var_decl 0x7f20d6b58f00 codecForCStrings type <pointer_type
0x7f20d6bd9900>
            used public private static unsigned external nonlocal
in_system_header decl_3 decl_5 decl_6 SI file /usr/include/QtCore/qstring.h
line 577 col 24 size <integer_cst 0x7f20d9e00a50 32> unit size <integer_cst
0x7f20d9e006c0 4>
            align 32 context <record_type 0x7f20d7710840 QString>
            chain <type_decl 0x7f20d6b65900 QString>>>
    /usr/include/QtCore/qstring.h:670:58>
$33 = void
(gdb) p debug_tree(MEM_ATTRS(y)->expr)
 <component_ref 0x7f20d4093190
    type <pointer_type 0x7f20d6bd96c0
        type <record_type 0x7f20d6bd8d80 Data type_5 BLK
            size <integer_cst 0x7f20d7fd4510 constant 160>
            unit size <integer_cst 0x7f20d7fd44b0 constant 20>
            align 32 symtab 0 alias set 87 canonical type 0x7f20d6bd8d80 fields
<field_decl 0x7f20d6b58640 ref> context <record_type 0x7f20d7710840 QString>
            full-name "struct QString::Data"
            X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
            pointer_to_this <pointer_type 0x7f20d6bd96c0> chain <type_decl
0x7f20d6bd8e40 Data>>
        sizes-gimplified unsigned SI
        size <integer_cst 0x7f20d9e00a50 constant 32>
        unit size <integer_cst 0x7f20d9e006c0 constant 4>
        align 32 symtab 0 alias set 32 canonical type 0x7f20d6bd96c0
        pointer_to_this <pointer_type 0x7f20d6a15d80> reference_to_this
<reference_type 0x7f20d6be3a80>>

    arg 0 <var_decl 0x7f20d408e320 cpy
        type <record_type 0x7f20d74f5b40 QString readonly sizes-gimplified
addressable needs-constructing type_1 type_4 type_5 type_6 BLK size
<integer_cst 0x7f20d9e00a50 32> unit size <integer_cst 0x7f20d9e006c0 4>
            align 32 symtab 0 alias set -1 canonical type 0x7f20d74f5b40
            attributes <tree_list 0x7f20d6b64b10
                purpose <identifier_node 0x7f20d7fd2f00 visibility
                bindings <(nil)>
                local bindings <(nil)>>
                value <tree_list 0x7f20d6b64ae0
                    value <string_cst 0x7f20d6b64ab0 type <array_type
0x7f20d7710b40>
                        readonly constant static "default\000">>> fields
<const_decl 0x7f20d6b57280 SectionDefault>
            full-name "const class QString"
            needs-constructor needs-destructor X() X(constX&) this=(X&)
n_parents=0 use_template=0 interface-unknown
            pointer_to_this <pointer_type 0x7f20d6b68f00> reference_to_this
<reference_type 0x7f20d74f5c00>>
        addressable used tree_1 tree_2 tree_3 in_system_header decl_1 decl_5
BLK file /usr/include/QtCore/qlist.h line 420 col 21 size <integer_cst
0x7f20d9e00a50 32> unit size <integer_cst 0x7f20d9e006c0 4>
        align 32 context <function_decl 0x7f20d5f90800 __comp_ctor >
abstract_origin <var_decl 0x7f20d5553be0 cpy>
        (mem/s/c:BLK (plus:SI (reg/f:SI 20 frame)
        (const_int -3828 [0xfffffffffffff10c])) [31 cpy+0 S4 A32])>
    arg 1 <field_decl 0x7f20d6b58e60 d type <pointer_type 0x7f20d6bd96c0>
        used private unsigned nonlocal decl_3 SI file
/usr/include/QtCore/qstring.h line 574 col 11 size <integer_cst 0x7f20d9e00a50
32> unit size <integer_cst 0x7f20d9e006c0 4>
        align 32 offset_align 128
        offset <integer_cst 0x7f20d9e006f0 constant 0>
        bit offset <integer_cst 0x7f20d9e232d0 constant 0> context <record_type
0x7f20d7710840 QString>
        chain <var_decl 0x7f20d6b58f00 codecForCStrings type <pointer_type
0x7f20d6bd9900>
            used public private static unsigned external nonlocal
in_system_header decl_3 decl_5 decl_6 SI file /usr/include/QtCore/qstring.h
line 577 col 24 size <integer_cst 0x7f20d9e00a50 32> unit size <integer_cst
0x7f20d9e006c0 4>
            align 32 context <record_type 0x7f20d7710840 QString>
            chain <type_decl 0x7f20d6b65900 QString>>>
    /usr/include/QtCore/qstring.h:670:58>
$34 = void
(gdb) 

So the expressions look exactly the same when printed ("cpy.d") but they are
actually not the same variable.  OK.  False alarm.  Pfew...


-- 


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

[Bug rtl-optimization/39077] [4.3/4.4/4.5 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[rguenth at gcc dot gnu dot org]

------- Comment #15 from rguenth at gcc dot gnu dot org  2009-08-04 12:29 -------
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.4                       |4.3.5


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

[Bug rtl-optimization/39077] [4.3/4.4/4.5 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[steven at gcc dot gnu dot org]

------- Comment #16 from steven at gcc dot gnu dot org  2010-02-20 17:58 -------
Finally (!) posted the patch...


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2010-
                   |                            |02/msg00824.html
           Keywords|                            |patch


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

[Bug rtl-optimization/39077] [4.3/4.4/4.5 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[comer352l at googlemail dot com]

------- Comment #17 from comer352l at googlemail dot com  2010-02-22 15:09 -------
Great, thank you Steven !
Will this patch also improve compilation time ? It currently needs about 45
seconds with 4.4.3 on a Athlon64X2-5000+ (even with -fnogcse).

In the meantime I managed to test on a windows machine with a recent version
(4.4.0) and the size increase doesn't occur there (but compilation is extremely
slow, too).


-- 


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

[Bug rtl-optimization/39077] [4.3/4.4/4.5/4.6 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[comer352l at googlemail dot com]

------- Comment #18 from comer352l at googlemail dot com  2010-04-09 15:35 -------
(In reply to comment #17)
> In the meantime I managed to test on a windows machine with a recent version
> (4.4.0) and the size increase doesn't occur there (but compilation is extremely
> slow, too).

Sorry, it seems I've made a mistake during my last test: the size increasing
occurs on Windows, too.


-- 


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

[Bug rtl-optimization/39077] [4.3/4.4/4.5/4.6 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)

[rguenth at gcc dot gnu dot org]

------- Comment #19 from rguenth at gcc dot gnu dot org  2010-05-22 18:13 -------
GCC 4.3.5 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.5                       |4.3.6


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