Re: Put scope blocks on a diet

[Jan Hubicka <jh at suse dot cz>]

> Jan Hubicka wrote:
> 
> > It looks like I've got lost somewhere in this thread. 
> 
> Me too.
> 
> > My understanding
> > is that:
> >   - My July 24/26 changes introducted DECL_UID divergence because of
> >     correlation of SCOPE block prunning and inlininer duplicating them
> >   - Alexandre's and mine patch comitted at Nov 26 reverted this
> >     behaviour so DECL_UIDs are now stable because we prune after
> >     inlining only
> >   - This patch causes memory consumption increase relative to Jul
> >     26-Nov26 compiler at -g, but not at -g0 that started this thread
> 
> So, in other words, you think we're back at the point we were before the
> July changes, in terms of both -g vs. -g0 and in terms of memory
> consumption?

The patch from July 24/26 is doing two things:
  1. it looks for completely dead scopes that will never go to debug info
  and removes them early instead of keeping them in memory until
  end of compilation, when they would be just ingored by dwarf2out
  because they are dead.
  2. when debug is not generated, it removes almost all scopes to save
  memory.

Both 1. and 2. resulted in memory savings.  1. at -g and -g0, 2. at -g0
only.  I don't remember exact numbers, but 1. was already quite
considerable saving on tramp3d testcase as well as other C++ testcases.

2. is the troublesome change (I've missed the inliner/DECL_UID
correlation when doing the patch) that was targetted by Nov26 patch to enable
2. only fater inlining. 1. is safe in this respect since it does not
make any difference in between -g and -g0 compilation.

So I believe that current mainline is still keeping less debug info in
memory mainly because of 1. and in some cases because of 2. at least for
testcases with single huge function and unless I've missed some extra
problems, I think it is best to keep it as it is until we develop better
in memory representation of debug info.

Removing the July patches and November fix would just increase memory
footprint.

Honza
> 
> If so, then I agree that I don't see any need for further action.
> 
> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713