This is the mail archive of the
mailing list for the GCC project.
Re: [bitmap memory]: Allocation part 2
- From: Nathan Sidwell <nathan at codesourcery dot com>
- To: law at redhat dot com
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Roger Sayle <roger at eyesopen dot com>,Daniel Berlin <dberlin at dberlin dot org>
- Date: Tue, 23 Nov 2004 09:38:28 +0000
- Subject: Re: [bitmap memory]: Allocation part 2
- Organization: Codesourcery LLC
- References: <41A21524.email@example.com> <firstname.lastname@example.org>
Jeffrey A Law wrote:
4) There is a tendency for newer code to never use stack-frame allocated
bitmaps, instead always using a dynamically allocated one. Should
we remove the stack-frame allocation mechanism? I'd guess the runtime
saving of using it to be negligible.
I wasn't even aware of them :-) There are places where having them on
the stack makes sense from a maintenance point of view. However, I tend
to dislike allocating potentially large objects on the stack. So my
vote would be to kill them.
I was unclear. What is allocated on the stack is the bitmap_head (a 4 slot
struct), the elements themselves will go on an obstack. The function ends
up passing an address of a stack slot, rather than a pointer obtained from
BITMAP_ALLOC(). IMHO, this interface is additional maintainance burden
for no gain.
I shall think about how best to do this.
That patch is, err, long. Is there any way you can break it into
distinct functional hunks to make review easier?
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
email@example.com :: http://www.planetfall.pwp.blueyonder.co.uk