[Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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 <jakub at gcc dot gnu.org> changed:
> > 
> >            What    |Removed                     |Added
> > ----------------------------------------------------------------------------
> >                  CC|                            |jakub at gcc dot gnu.org
> > 
> > --- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> > 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.