[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 #6 from rguenther at suse dot de <rguenther at suse dot de> 2011-12-20 15:38:16 UTC ---
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).

Richard.