Release RTL bodies after compilation (sometimes)

[Jan Hubicka]

> On Tue, 2004-09-14 at 15:19, Diego Novillo wrote:
> > On Tue, 2004-09-14 at 16:51, Jeffrey A Law wrote:
> > 
> > > The problem is your change to explicitly call ggc_free bypasses the
> > > entire GC mechanisms we've built.  As I've stated before, if you
> > > can't be absolutely sure that there are no pointers left into your
> > > object, then the object is _NOT_ a candidate for ggc_free.  I can't
> > > emphasize this enough.
> > > 
> > Heartily agree.  Sprinkling ggc_free is a dead give away that we are
> > papering over some basic memory management design problem.
> > 
> > Either we shouldn't be using GC here, or the collection mechanism is not
> > good enough.  All this random explicit deallocation is a perfect recipe
> > for disaster and extremely hard to track bugs.
> You know, if calling ggc_free "fixes" a memory leak, then well, the
> ggc_free is wrong, no other way to look at it.
> 
> ggc_free's only purpose should be to return objects to the GC pool
> faster (ie, before the next collection point).  Any other use is
> simply wrong.

Of course this is what I am trying to use ggc_free for.

We already do have checking so garbage collector crash badly first time
it sees pointer to explicitly freed object, so the bugs does not appear
to be that difficult to notice with gcac and we can't use ggc_free for
objects with some pointers left to this.

Sorry for breakage in this case - it bootstrapped x86-64 and until quite
recently we use explicit malloc/free pairs on CFG so it seemed safe to
me.
Still it seems to be bug to keep pointers to dead basic blocks in the
insn chain actually.

Honza
> 
> jeff
>