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.
