This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ggc_free


> > On Fri, Jan 23, 2004 at 02:03:12AM +0100, Jan Hubicka wrote:
> > > I think I can use this instead of old_* use in init_emit patch and alias
> > > analysis patch.
> > 
> > Good.  Probably the only other thing that would be needed is 
> > for VARRAY_FREE to DTRT.
> > 
> > > (the second one has been approved, the first one is still waiting)
> > 
> > Assuming this ggc_free is going to work, I'd prefer they both
> > be updated.
> > 
> > 
> > > I still think in favour of using alloc_pool for allocating very many of
> > > very tiny objects just because it allows easy statistics, has better
> > > locality and minimal overhead.
> > 
> > Here I completely agree.
> > 
> > > Similarly I preffer allocating things outside GGC memory completely
> > > whenever possible most of my other patches are around.  If you think I
> > > should avoid this scheme, just tell me so I don't produce too much work
> > > in this.
> > 
> > Another that I wonder about is the insn_address change, which
> > more or less re-implements VARRAY just to avoid GGC.  I'm not
> > sure I like this.
> 
> Yes.  In fact the sollution this is result of my earlier discussion with
> Jeff, where I was just considering to add VARRAY support to grow in the
> malloc memory on choice.  My understand of Jeff's comment was that he
> want the varrays to go for hot datastructures in favour of more
> specifically tunned ways.  I was unsure what to do with the
> INSN_ADDRESSES array then and ended up with this sollution.
> 
> The only advantage of the new thing is that it avoid clearing out the
> array that is probably not big deal at all and I would not worry about
> dropping this patch.
> 
> I am using similar array to hold the log links in my patch too, perhaps
> I can turn it into varray too, but then I will get it walked by GGC that
> I don't want to happen (I want to rely on fact htat log links never
> points to dead instructions)

To expand this, I am shooting for any instruction reachable for GGC
outside main insn chain to be error.

Honza
> 
> Honza
> > 
> > 
> > r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]