Re: New VEC API

[Nathan Sidwell <nathan at codesourcery dot com>]

Giovanni Bajo wrote:
> Nathan Sidwell <nathan@codesourcery.com> wrote:
>
>
> > > The accessors that cannot cause allocation do not need to mention the
> > > allocation mechanism.  I.e.
> > > VEC_length(tree,v);  // how long is this vector (be it none,gc or
> > > heap)
> > > but when allocation might occur, you have to specify
> > > VEC_safe_push(tree,gc,v,node);  // push onto end.
>
>
> What happens if you specify a wrong allocation type in such a function?
> Would it be possible to assert this condition in ENABLE_CHECKING mode, at the
> expense of (maybe) a slightly larger vec structure?

you get a type mismatch compile error and/or a 'no such function' error.
[this is what I mean by 'type safe']

> > > 1) duplicate adjacent calls to VEC_safe_push.  I changed these to
> > > VEC_reserve (2), VEC_quick_push (...), VEC_quick_push (...)
>
>
> Assuming exponential grow, shouldn't the overhead of two consecutive safe_push
> be negligible?

correct. but the code size will be larger.  It'll look like
	if (!space_for (1))
		extend_vec()1
	push (a)
	if (!space_for (1))
		extend_vec(1)
	push (b)

and the compiler will not be able to optimize both those pushes into
	*ptr++ = a;
	*ptr++ = b;

The conversion will make it look like
	if (!space_for (2))
		extend_vec(2)
	push (a)
	push (b)
which is more optimizer friendly.

A few hundred bytes here, a few hundred there, pretty soon we're talking
real memory :)

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk