public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions Date: Mon, 09 Mar 2015 15:26:00 -0000 [thread overview] Message-ID: <bug-44563-4-uXks1sN1ap@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-44563-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 --- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Richard Biener from comment #16) > callgrind shows the cgraph_edge_hasher quite high in the profile (via > redirect_all_calls). I suppose as the large main is a single BB walking > all stmts over-and-over is quite bad. Also hash_pointer isn't inlined!? > Ah - it's external in libiberty hashtab.c ... - it should transition to > using/inheriting from pointer_hash. > > cgraph_edge * > cgraph_node::get_edge (gimple call_stmt) > { > cgraph_edge *e, *e2; > int n = 0; > > if (call_site_hash) > return call_site_hash->find_with_hash (call_stmt, > htab_hash_pointer (call_stmt)); > Btw, for 10000 calls (smaller testcase) we get 100 000 000 calls to cgraph_edge::redirect_call_stmt_to_callee () (that's from 40000 redirect_all_calls calls which is from 10000 optimize_inline_calls calls). Ah - we do this also for the ENTRY/EXIT block! Index: gcc/tree-inline.c =================================================================== --- gcc/tree-inline.c (revision 221278) +++ gcc/tree-inline.c (working copy) @@ -2802,11 +2802,13 @@ copy_cfg_body (copy_body_data * id, gcov if (need_debug_cleanup && bb->index != ENTRY_BLOCK && bb->index != EXIT_BLOCK) - maybe_move_debug_stmts_to_successors (id, (basic_block) bb->aux); - /* Update call edge destinations. This can not be done before loop - info is updated, because we may split basic blocks. */ - if (id->transform_call_graph_edges == CB_CGE_DUPLICATE) - redirect_all_calls (id, (basic_block)bb->aux); + { + maybe_move_debug_stmts_to_successors (id, (basic_block) bb->aux); + /* Update call edge destinations. This can not be done before loop + info is updated, because we may split basic blocks. */ + if (id->transform_call_graph_edges == CB_CGE_DUPLICATE) + redirect_all_calls (id, (basic_block)bb->aux); + } ((basic_block)bb->aux)->aux = NULL; bb->aux = NULL; } makes sense? > The estimate_calls_size_and_time portion is quite smaller. > > cleanup-cfgs main portion is split_bb_on_noreturn_calls.
next prev parent reply other threads:[~2015-03-09 15:26 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-44563-4@http.gcc.gnu.org/bugzilla/> 2010-12-12 23:55 ` hubicka at gcc dot gnu.org 2010-12-13 0:58 ` hubicka at gcc dot gnu.org 2010-12-13 1:00 ` hubicka at gcc dot gnu.org 2010-12-13 1:07 ` hubicka at gcc dot gnu.org 2010-12-13 1:17 ` hubicka at gcc dot gnu.org 2010-12-13 1:47 ` hubicka at gcc dot gnu.org 2010-12-13 13:22 ` hubicka at gcc dot gnu.org 2010-12-17 0:08 ` hubicka at gcc dot gnu.org 2015-03-07 0:22 ` hubicka at gcc dot gnu.org 2015-03-09 9:36 ` rguenth at gcc dot gnu.org 2015-03-09 11:33 ` rguenth at gcc dot gnu.org 2015-03-09 15:26 ` rguenth at gcc dot gnu.org [this message] 2015-03-09 15:36 ` rguenth at gcc dot gnu.org 2015-03-10 4:55 ` hubicka at ucw dot cz 2015-03-10 8:26 ` rguenth at gcc dot gnu.org 2015-03-10 8:35 ` rguenther at suse dot de 2015-03-10 11:54 ` rguenth at gcc dot gnu.org 2015-03-10 12:03 ` rguenth at gcc dot gnu.org 2015-03-10 12:31 ` jakub at gcc dot gnu.org 2015-03-10 12:44 ` rguenth at gcc dot gnu.org 2015-03-10 12:51 ` rguenther at suse dot de 2015-03-10 13:19 ` rguenth at gcc dot gnu.org 2015-03-12 15:09 ` rguenth at gcc dot gnu.org 2015-03-13 8:43 ` [Bug ipa/44563] " rguenth at gcc dot gnu.org 2015-03-13 8:47 ` rguenth at gcc dot gnu.org 2015-03-13 8:53 ` rguenth at gcc dot gnu.org 2015-03-13 8:55 ` rguenth at gcc dot gnu.org 2015-03-16 0:07 ` hubicka at ucw dot cz 2024-02-16 13:52 ` rguenth at gcc dot gnu.org 2010-06-17 4:10 [Bug c/44563] New: " jvoss at altsci dot com 2010-06-17 4:14 ` [Bug tree-optimization/44563] " jvoss at altsci dot com 2010-06-17 10:37 ` rguenth at gcc dot gnu dot org 2010-06-17 10:45 ` rguenth at gcc dot gnu dot org 2010-06-17 12:28 ` jakub at gcc dot gnu dot 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-44563-4-uXks1sN1ap@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: linkBe 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).