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:
>  >> 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 whic
>  >h
>  >> exist solely because other datastructures and interfaces are poorly designe
>  >d
>  >> (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?
> Nothing specifically.  I'm not trying to address the class of problems
> where varrays actually do make sense.
>  >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...
> When varrays make sense, then we should use varrays.  When varrays do not
> make sense, then we should not use varrays.
> My point is we have places where we needless use (and resize) varrays
> where we really don't need varrays to begin with because of poor
> design/implementation decisions.

OK then,
shall I finish my patch adding extra argument to VARRAY_INIT choosing
allocator technique for benefit of arrays, like INSN_ADDRESSes are?
(I admit that there are not that many of them in mainline), or you think
there is better sollution for this particular problem?
(still the clearing of array is redundant, but it shall not be major

> jeff

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