This is the mail archive of the 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

> In message <>, Jan Hubicka writes:
>  >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.
> More correctly, we have some uses of varrays (block_{true,false}_exprs which
> exist solely because other datastructures and interfaces are poorly designed
> (the dominator optimizer's hash tables for example).
> In other cases we have varrays for objects which could just as easy be
> malloc'd -- the only thing varrays buy is for those objects is bounds
> checking.  The const_and_copies table in the dominator optimizer is an
> excellent example.

INSN_ADDRESSES is example of VARRAY that needs to grow in some corner
cases, shall have bounds checking, don't need to be cleared and can
live in malloced memory.  What would you propose to do here?
I am still bit in a dark - the idea of adding flag for deciding whether
varray shall be in GGC pool or not does not seem to be good,
implementing just different varray neither...
> jeff

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