This is the mail archive of the
mailing list for the GCC project.
Re: [trunk<-vta] Re: [vta, 4.4] make df-scan df_collection_rec arrays overflow-safe
- From: Ian Lance Taylor <iant at google dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 01 Jun 2009 09:26:14 -0700
- Subject: Re: [trunk<-vta] Re: [vta, 4.4] make df-scan df_collection_rec arrays overflow-safe
- References: <firstname.lastname@example.org> <email@example.com>
Alexandre Oliva <firstname.lastname@example.org> writes:
>> So I came up with a trade-off that should benefit nearly everyone.
>> First, I arranged for the array to start out still on the stack, but
>> to grow as needed onto the heap. Using GC memory for growth would
>> work, but it was easy enough to add explicit deallocation where
>> And then, given that the array could now grow unbounded, the initial
>> sizes didn't have to be so outrageously conservative, so I've reduced
>> stack usage while at that. No biggie, but still...
I like the idea but (sorry) I would rather see this as a more general
data structure which can be used in other places. I don't like the ##
stuff you are using. Perhaps if you defined a new type of VEC:
VEC(TYPE, alloca). This would be a different data structure from the
existing VEC types, but the interface could otherwise be the same. For
example, VEC_alloc would always alloca, say, 256 bytes of stack space.
When more was needed, it would switch to malloc.
Does anybody think that would be a bad idea?