Re: Pre-inline optimization, version 3

[Jan Hubicka <jh at suse dot cz>]

> > Hi,
> > > 
> > > In any case, this particular patch does not look right to me.
> > > sizeof (t) is simply 4.  If you want to clear out all the fields, I
> > > think you need to use tree_code_size (TREE_CODE (t)) (which in this
> > > case is sizeof (struct tree_ssa_name)).  And that should probably be
> > > done via a function in tree.c.
> > 
> > Yes, you are right, it was meant to be tree_code_size (SSA_NAME) that
> > was what I used to have on this place before I decided to change to
> > ggc_free. I retyped the patch in sort of hurry and forgot about it.
> > I have put there the ggc_free because ...
> > > 
> > > And in any case a much simpler mechanism to use the GC is to skip the
> > > loop entirely and just set FREE_SSANAMES (cfun) to NULL.
> > 
> > This is the actual problem.  If you FREE_SSANAMES (cfun) you would think
> > that all SSA_NAMES will be recycled, but as I found hard way they are
> > not.  The problem is that as soon as we leak single pointer from GGC
> > visible memory (as all the apperances in question) into the freelist,
> > GGC will walk basically entire freelist, because all the free ssa names
> > are linked together and all points out to dead variables, that points to
> > annotations that further points to dead statements keeping the whole
> > original GIMPLE memory footprint before optimization.
> > 
> > >From tramp3d about 80% of SSA names are dead after early optimization
> > and without the few fixes I found even with FREE_SSANAMES set to zero,
> > _all_ was kept alive over whole compilation unit increasing memory usage
> > by 200MB, or 20%.  The numbers are bit less steep in C testcases, just
> > about 40% of SSA names are dead.

Actually I was wrong in this claims, I must apologize for it.  The
SSA_NAMES freelist is actually not dragging in variables/annotations
because we already clear it out in release_ssa_name via:

      memset (var, 0, tree_size (var));

I've re-run the tests and the 200MB/20% savings was actually caused by
the code before releasing the freelist:

  /* Current defs point to various dead SSA names that in turn points to dead
     statements so bunch of dead memory is holded from releasing.  */
  FOR_EACH_REFERENCED_VAR (t, rvi)
    set_current_def (t, NULL);

Of course I found this particular problem with the ggc_free trick on SSA
names (ie garbage collection crashed on current_defs pointing to dead
statements pointing to dead SSA names).

Since the freelists accounts about 3% of footprint, I would be also
happy with the patch removing the whole releasing loop and I can do
occasional checking myself trying to plug major offenders if this seems
easisest from maintenance POV.

The current_def example however shows how easy is it to introduce huge
memory consumption this way and keep it unnoticed.  

Honza