This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [rfc] coalesce stack slots
- From: Nathan Sidwell <nathan at codesourcery dot com>
- To: Nathan Myers <ncm at cantrip dot org>
- Cc: gcc-patches at gcc dot gnu dot org, rth at redhat dot com, rasky at develer dot com, dberlin dot dberlin dot org at itasoftware dot com
- Date: Tue, 07 Sep 2004 20:27:50 +0100
- Subject: Re: [rfc] coalesce stack slots
- Organization: Codesourcery LLC
- References: <1094577729.29347.863.camel@ipc>
Nathan Myers wrote:
Richard Henderson wrote:
That and Nathan [Sidwell]'s VEC's appear to only be able to
"add N to the current size" rather than "set total size to N".
At which point I quit looking.
When we were designing the reserve() member of the C++ standard
library template std::vector<>, several people thought its argument
should be relative to the current capacity, but I insisted that
reserve's argument should become the absolute capacity of the
vector. (After a reserve() call, an append() is guaranteed not
to trigger a reallocation if all the elements fit in the reserved
size.)
hehe, I had that discussion with myself for this API :)
I "won", but I still find it hard to articulate precisely why it
was right. If you can explain it, posterity might benefit.
The 'reserve' functionality we have is 'reserve space for N additional
live members' _not_ space for N additional members on top whatever
additional space is already there. Or another way to think about it
is 'allocate space now so that the next N pushes/inserts won't
reallocate' (so you can use the quick versions of those functions,
rather than the slower ones). This has proved to be the right choice
for the uses so far.
To get the std::vector semantics you'd have to add or subtract the
current live length (depending on which way you're going).
I've not yet looked at rth's code.
nathan
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk