http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-21
09:29:05 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > On Tue, 20 Dec 2011, Richard Guenther wrote:
> > > > This one is extremely slow. lto1 has already used 12min of CPU time when
> > > > linking libxul and is still running... (3min is normal)
> > >
> > > 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?
>
> Increasing the cache 4-fold doesn't help.
> I will look deeper tomorrow. In the meantime here is a disassembly of the
> hot-spot.
>
> uniquify_nodes:
> : /* Second fixup all trees in the new cache entries. */
> : for (i = len; i-- > from;)
> 0.00 : 49969f: mov %ebp,%eax
> 0.00 : 4996a1: jmpq 4994b0 <lto_read_decls+0x110>
> 0.00 : 4996a6: nopw %cs:0x0(%rax,%rax,1)
> : tree t = VEC_index (tree, cache->nodes, i);
> : if (t == NULL_TREE)
> : continue;
> :
> : if (TREE_CODE (t) == VAR_DECL)
> : lto_register_var_decl_in_symtab (data_in, t);
> 0.00 : 4996b0: mov 0x38(%rsp),%rdi
> 0.00 : 4996b5: callq 499250
> <lto_register_var_decl_in_symtab>
> 0.00 : 4996ba: jmpq 499520 <lto_read_decls+0x180>
> : variant list state before fixup is broken. */
> : tree tem, mv;
> :
> : /* Remove us from our main variant list if we are
> not the
> : variant leader. */
> : if (TYPE_MAIN_VARIANT (t) != t)
> 0.00 : 4996bf: mov 0x68(%r15),%rdi
> 0.00 : 4996c3: cmp %rdi,%r15
> 0.00 : 4996c6: je 499701 <lto_read_decls+0x361>
> : {
> : tem = TYPE_MAIN_VARIANT (t);
> : while (tem && TYPE_NEXT_VARIANT (tem) != t)
> 0.00 : 4996c8: test %rdi,%rdi
> 0.00 : 4996cb: je 4996f9 <lto_read_decls+0x359>
> 0.00 : 4996cd: mov 0x60(%rdi),%rax
> 0.00 : 4996d1: cmp %rax,%r15
> 0.00 : 4996d4: jne 4996e3 <lto_read_decls+0x343>
> 0.00 : 4996d6: jmpq 4997d9 <lto_read_decls+0x439>
> 0.00 : 4996db: nopl 0x0(%rax,%rax,1)
> 0.50 : 4996e0: mov %rcx,%rax
> 0.70 : 4996e3: test %rax,%rax
> 0.00 : 4996e6: je 4996f9 <lto_read_decls+0x359>
> 0.00 : 4996e8: mov 0x60(%rax),%rcx
> 98.41 : 4996ec: cmp %rcx,%r15
> 0.00 : 4996ef: jne 4996e0 <lto_read_decls+0x340>
> : tem = TYPE_NEXT_VARIANT (tem);
> : if (tem)
> : TYPE_NEXT_VARIANT (tem) = TYPE_NEXT_VARIANT
> (t);
> 0.00 : 4996f1: mov 0x60(%r15),%rcx
> 0.00 : 4996f5: mov %rcx,0x60(%rax)
> : TYPE_NEXT_VARIANT (t) = NULL_TREE;
> 0.00 : 4996f9: movq $0x0,0x60(%r15)
> : }
> :
> : /* Query our new main variant. */
> : mv = gimple_register_type (TYPE_MAIN_VARIANT (t));
> 0.01 : 499701: callq 5be860 <gimple_register_type>
> :
> : /* If we were the variant leader and we get
> replaced ourselves drop
> : all variants from our list. */
> : if (TYPE_MAIN_VARIANT (t) == t
> 0.00 : 499706: mov 0x30(%rsp),%rdx
> 0.00 : 49970b: cmp 0x68(%rdx),%rdx
> 0.00 : 49970f: je 4997b7 <lto_read_decls+0x417>
> : }
> : }
> :
> : /* If we are not our own variant leader link us
> into our new leaders
> : variant list. */
> : if (mv != t)
> 0.00 : 499715: cmp %rax,0x30(%rsp)
> 0.00 : 49971a: je 49992d <lto_read_decls+0x58d>
> : {
That's weird. Did the build eventually finish? LTO bootstrap went fine
for me, but SPEC 2k6 483.xalancbmk build ran out of memory during LTRANs
(in theory we should end up using _less_ memory with the change ...)
