[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> 2011-12-20 15:40:01 UTC ---
On Tue, 20 Dec 2011, Richard Guenther wrote:

> On Tue, 20 Dec 2011, markus at trippelsdorf dot de wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
> > 
> > --- Comment #5 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-20 15:31:47 UTC ---
> > (In reply to comment #4)
> > > Doesn't work.  Instead testing a similar
> > > 
> > > Index: gcc/lto/lto.c
> > > ===================================================================
> > > --- gcc/lto/lto.c       (revision 182525)
> > > +++ gcc/lto/lto.c       (working copy)
> > > @@ -845,6 +845,14 @@ uniquify_nodes (struct data_in *data_in,
> > >                     if (ix < i)
> > >                       lto_fixup_types (f2);
> > >                     streamer_tree_cache_insert_at (cache, f1, ix);
> > > +                   /* Make sure that the type of a TYPE_DECL refers
> > > +                      to the type decl that prevails in the prevailing
> > > +                      record or union type.  */
> > > +                   if (TREE_CODE (f1) == TYPE_DECL)
> > > +                     {
> > > +                       tree f1t = gimple_register_type (TREE_TYPE (f1));
> > > +                       TYPE_NAME (f1t) = f1;
> > > +                     }
> > >                   }
> > >             }
> > 
> > This one is extremely slow. lto1 has already used 12min of CPU time when
> > linking libxul and is still running... (3min is normal)
> > 
> > "perf top" shows:
> >  27.92%  lto1                           [.] lto_read_decls
> >  14.79%  lto1                           [.] htab_find_slot_with_hash
> >   9.37%  lto1                           [.] gimple_type_eq
> >   6.39%  libc-2.14.90.so                [.] _int_malloc
> >   5.60%  [kernel]                       [k] 0xffffffff81037d72
> >   4.80%  lto1                           [.] gtc_visit
> >   3.68%  libc-2.14.90.so                [.] memset
> 
> That's odd - TREE_TYPE (f1) should already be registered - but I suppose
> that adjusting TYPE_NAME might break all the caching we do with the
> type-pair cache as TREE_TYPE (TYPE_NAME (f1)) is in the SCC of the
> type we change that SCC by that adjustment - probably causing
> the hit rate of the type-pair compare cache to become absymal?
> Maybe you can check that theory (I have no other idea why the above
> should be slow).

Though we should be hitting the gimple_type_leader cache only ...
maybe it's too small though?