Re: Kill pointers keeping gimple function body around after RTL is generated

[Jan Hubicka <jh at suse dot cz>]

> On Fri, 2004-09-03 at 14:05, Jan Hubicka wrote:
> > > On Fri, 2004-09-03 at 02:03, Jan Hubicka wrote:
> > > 
> > > > The freeing is not ready yet as we are leaking SSA_NAMES that are no
> > > > longer referenced by code, but referenced by the ssa_names varray
> > > > pointing to the dead statements so we get a abort during GGC run.
> > > We've certainly never made an attempt to release every SSA_NAME.
> > > Most leaks are likely to be in the DCE code, but I wouldn't be
> > > terribly surprised to find them elsewhere as well.
> > > 
> > > What might make sense is to release all the SSA names after we 
> > > go out of SSA form, that ought to help.
> > 
> > The problem is that leaking SSA_NAMES kills the idea of explicitely
> > freeing the memory used by GIMPLE statements since GGC will crash once
> > seeing the pointer to already released data.
> And I consider that actually a *GOOD* thing.  What you're doing is
> basically bypassing the entire memory management system we have
> built.  That seems bad.
> 
> I think if you start going down this path of trying to explicitly
> release statement memory via ggc_free, you're going to introduce
> a whole class of hard to find problems.  In effect you're taking
> us back down the obstack path in a lot of ways.
> 
> While I would encourage identifying and fixing any leaks of SSA_NAMEs
> which are easily resolved.  You might even reach a point where we
> do not leak SSA_NAMEs, which would be good.  However, I don't think
> we should be looking at deallocating statement memory on the fly.

OK, one the one way you say that it is good to have leaks and on the
other way that is is good to fix them...  I don't think we are in basic
disagreement on this side.  Basically I want to give a try to freeing
statements as it finds the leaks and I am curious how it will affect the
perofmrance.

The reason why I would like it to try is that we are running into all
sort of performance problem and our memory management system is one of
components that apparently don't scale very well.

Basically about every other compiler I seen does have some kind of
explicit memory management on the instruction as it is relatively
convenient to do so (instruction in insn chain is live, instruction
removed is dead).  I am not going to push that anywhere unless it is
going to be interesting.

I would be also curious what class of hard problems it would bring.  So
far it exposes the leaks that is not too bad thing and easy to debug as
well.  Last year I tried for fun the idea on RTL and it did work too
except for exposing the wrong RTL sharing cases that are just timed
bombs anyway too.
> 
> 
> > One alternative might be to avoid GGC from actually travelling the
> > pointer as live SSA_NAME should never point to dead statement anyway if
> > it looks any better...
> This sounds like a horrible idea as well.

What would you say can break?

Honza
> 
> jeff