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?
