From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12407 invoked by alias); 20 Dec 2011 18:06:57 -0000 Received: (qmail 12394 invoked by uid 22791); 20 Dec 2011 18:06:55 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_BX,TW_IB,TW_OV X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Dec 2011 18:06:40 +0000 From: "markus at trippelsdorf dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul Date: Tue, 20 Dec 2011 18:12:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: markus at trippelsdorf dot de X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-12/txt/msg02290.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635 --- Comment #8 from Markus Trippelsdorf 2011-12-20 18:06:34 UTC --- (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 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 0.00 : 4996ba: jmpq 499520 : 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 : { : tem = TYPE_MAIN_VARIANT (t); : while (tem && TYPE_NEXT_VARIANT (tem) != t) 0.00 : 4996c8: test %rdi,%rdi 0.00 : 4996cb: je 4996f9 0.00 : 4996cd: mov 0x60(%rdi),%rax 0.00 : 4996d1: cmp %rax,%r15 0.00 : 4996d4: jne 4996e3 0.00 : 4996d6: jmpq 4997d9 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 0.00 : 4996e8: mov 0x60(%rax),%rcx 98.41 : 4996ec: cmp %rcx,%r15 0.00 : 4996ef: jne 4996e0 : 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 : : /* 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 : } : } : : /* 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 : {