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: [rfc] coalesce stack slots


On Sat, 2004-09-04 at 11:21 +0100, Nathan Sidwell wrote:
> Richard Henderson wrote:
> > On Fri, Sep 03, 2004 at 10:29:06AM -0400, Daniel Berlin wrote:
> > 
> >>>More a curiousity, but is there a specific reason for not using Nathan's
> >>>VECs here?
> >>
> >>VEC's are ggc_alloc'd, this has a very well defined lifetime, and uses
> >>xmalloc.
> >>
> >>No thing should be gc alloced before it's time :)
> If there is interest, I could augment the vecs so that you specify
> the allocation mechanism when defining the type.  Something like
> 	DEF_VEC_GC_P(T) // ggc-alloc'd
> 	DEF_VEC_MALLOC_P(T) // malloc/free'd

This would be great, actually.
I have quite a few VEC's in the linear loop transform stuff, and in the
upcoming structure field analyzer, and none of them actually need to be
ggc_alloc'd, but are simply because they use VEC.

You should probably add a new function (to both, just for consistency)
called VEC_free, that freed all memory allocated by the vector.
It doesn't actually have to do anything in the GGC case (or it could
call ggc_free, whatever).

> The allocation mechanism would become part of the vector type -- you
> couldn't have both a GC'd vector of FOO and a malloc'd vector of FOO.[1]
> This means you won't need to remember the allocation mechanism
> when using the vector accessors.
> 
> thoughts?



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