From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127574 invoked by alias); 10 Mar 2015 13:19:19 -0000 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 Received: (qmail 127516 invoked by uid 48); 10 Mar 2015 13:19:16 -0000 From: "rguenth at gcc dot 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: Tue, 10 Mar 2015 13:19:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 4.3.4 X-Bugzilla-Keywords: compile-time-hog, memory-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg01117.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 --- Comment #28 from Richard Biener --- (In reply to rguenther@suse.de from comment #27) > On Tue, 10 Mar 2015, jakub at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 > > > > Jakub Jelinek changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > CC| |jakub at gcc dot gnu.org > > > > --- Comment #25 from Jakub Jelinek --- > > Or perhaps add split_block variant that uses the old bb for the second part > > rather than the first one, and use it in the inliner? > > Seems like > > Index: gcc/tree-inline.c > =================================================================== > --- gcc/tree-inline.c (revision 221317) > +++ gcc/tree-inline.c (working copy) > @@ -4777,18 +4781,19 @@ static bool > gimple_expand_calls_inline (basic_block bb, copy_body_data *id) > { > gimple_stmt_iterator gsi; > + bool inlined = false; > > - for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi)) > + for (gsi = gsi_last_bb (bb); !gsi_end_p (gsi);) > { > gimple stmt = gsi_stmt (gsi); > + gsi_prev (&gsi); > > if (is_gimple_call (stmt) > - && !gimple_call_internal_p (stmt) > - && expand_call_inline (bb, stmt, id)) > - return true; > + && !gimple_call_internal_p (stmt)) > + inlined |= expand_call_inline (bb, stmt, id); > } > > - return false; > + return inlined; > } > > > fixes the issue as well as gsi stays valid over inline expansion if > we advance it before that. Funnily this makes us hit merge_blocks now via cleanup-tree-cfg walking BBs in block-number order (and the inliner now allocating blocks in a less "optimal" order...). This: 676 n = last_basic_block_for_fn (cfun); 677 for (i = NUM_FIXED_BLOCKS; i < n; i++) 678 { 679 bb = BASIC_BLOCK_FOR_FN (cfun, i); 680 if (bb) 681 retval |= cleanup_tree_cfg_bb (bb); 682 } should work (for merging blocks) from entry to exit but after new block assignment order now effectively works backwards :/ So the above doesn't really fix the issue but just shifts it elsewhere.