This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 12 Mar 2015 15:09:20 +0000
- Subject: [Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions
- Auto-submitted: auto-generated
- References: <bug-44563-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #29 from Richard Biener <rguenth at gcc dot gnu.org> ---
Sth like
@@ -672,8 +650,18 @@ cleanup_tree_cfg_bb (basic_block bb)
if (single_succ_p (bb)
&& can_merge_blocks_p (bb, single_succ (bb)))
{
- merge_blocks (bb, single_succ (bb));
- return true;
+ /* If there is a merge opportunity with the predecessor
+ do nothing now but wait until we process the predecessor.
+ This happens when we visit BBs in a non-optimal order and
+ avoids quadratic behavior with adjusting stmts BB pointer. */
+ if (single_pred_p (bb)
+ && can_merge_blocks_p (single_pred (bb), bb))
+ ;
+ else
+ {
+ merge_blocks (bb, single_succ (bb));
+ return true;
+ }
}
return retval;
in addition should do the job. Iteration on the predecessor should
cover both merges (so we don't actually need to revisit this block itself).