Pre-inline optimization, version 3

[Jan Hubicka]

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.

By putting ggc_free into this function I didn't meant to optimize number
of GGC runs (SSA_NAMEs itself are abour 3% of footprint that is hardly
too bad and I didn't cared to free the further more exensive
datastructures) but make it to crash when we ever leak pointer into the
freelist as it seemed still somewhat nicer solution than the alternative
of memseting out the link pointer/variable pointer and letting random
SSA names sturivve alnoe without dragging in the others SSA_NAMES,
variales and statements.

So the ggc_free does the work as expected - makes us to notice places we
have problem of keeping pointers to dead statements and names preventing
GGC from doing it's job.  Sadly it is firing more often than I would
like, but I think we basically have three options:

  1) Fix ggc_free ICEs as they appear
  2) Memset the pointers within SSA_NAME to 0 and let few SSA_NAMEs to
  leak alone
  3) Ignore the problem and pay the extra memory consumption

I tend to incline to 1 unless the progress is too hard, I would really
not be happy about 3 as it blocks any attempts to get inliner effectie
on high abstraction testcases.

Honza
> 
> Ian