public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "markus at trippelsdorf dot de" <gcc-bugzilla@gcc.gnu.org>
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 [thread overview]
Message-ID: <bug-51635-4-oB7K6eptT1@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-51635-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #8 from Markus Trippelsdorf <markus at trippelsdorf dot de> 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 <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>
: {
next prev parent reply other threads:[~2011-12-20 18:06 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-20 12:06 [Bug lto/51635] New: " markus at trippelsdorf dot de
2011-12-20 12:14 ` [Bug lto/51635] " rguenth at gcc dot gnu.org
2011-12-20 12:26 ` rguenth at gcc dot gnu.org
2011-12-20 14:42 ` rguenth at gcc dot gnu.org
2011-12-20 15:15 ` rguenth at gcc dot gnu.org
2011-12-20 15:38 ` markus at trippelsdorf dot de
2011-12-20 15:40 ` rguenther at suse dot de
2011-12-20 15:49 ` rguenther at suse dot de
2011-12-20 18:12 ` markus at trippelsdorf dot de [this message]
2011-12-21 9:38 ` rguenth at gcc dot gnu.org
2011-12-21 9:48 ` markus at trippelsdorf dot de
2011-12-21 11:04 ` rguenth at gcc dot gnu.org
2011-12-21 11:17 ` rguenth at gcc dot gnu.org
2011-12-21 12:58 ` markus at trippelsdorf dot de
2011-12-21 12:59 ` rguenth at gcc dot gnu.org
2011-12-21 13:01 ` rguenth at gcc dot gnu.org
2011-12-21 13:48 ` rguenth at gcc dot gnu.org
2011-12-21 14:01 ` markus at trippelsdorf dot de
2011-12-21 14:08 ` rguenther at suse dot de
2011-12-21 15:07 ` rguenth at gcc dot gnu.org
2011-12-21 15:11 ` rguenth at gcc dot gnu.org
2011-12-21 15:51 ` markus at trippelsdorf dot de
2011-12-21 16:02 ` rguenther at suse dot de
2011-12-21 16:09 ` rguenth at gcc dot gnu.org
2011-12-21 16:44 ` matz at gcc dot gnu.org
2011-12-22 10:15 ` markus at trippelsdorf dot de
2012-01-03 11:34 ` [Bug lto/51635] LTO should not merge (type) decls with different locations rguenth at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-51635-4-oB7K6eptT1@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).