This is the mail archive of the
mailing list for the GCC project.
Re: [bitmap memory]: Allocation part 2
- From: Jeffrey A Law <law at redhat dot com>
- To: Nathan Sidwell <nathan at codesourcery 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: Mon, 22 Nov 2004 15:21:10 -0700
- Subject: Re: [bitmap memory]: Allocation part 2
- Organization: Red Hat, Inc
- References: <41A21524.firstname.lastname@example.org>
- Reply-to: law at redhat dot com
On Mon, 2004-11-22 at 16:34 +0000, Nathan Sidwell wrote:
> This is the second part of my bitmap allocation cleanup work. The patch
> removes the malloc/free entry points, and renames the obstack ones as
> plain bitmap_alloc and bitmap_free. This is a mechanical patch.
> In doing this patch, I noticed a few things, on which comments are welcome
> 1) BITMAP_FREE sets the bitmap pointer to NULL, thus making it non-function
> like and different to plain free. Is this desirable? There are several
> places where the bitmap is explicitly NULLed after the call to BITMAP_FREE,
> indicating that this part of the interface is non-obvious.
Well, if you want to change that behavior, then you'll need to go to
BITMAP_FREE call site and determine if they need the bitmap NULLed or
not. I don't have a particularly strong preference here.
> 2) Should ALLOC_REG_SET take no obstack parameter, and always allocate
> from reg_obstack?
> 3) Should we be maintaining the distinction between regsets and bitmaps?
> I noticed several places where we mix the two types up.
Excellent question. I'm certainly not aware of anything which makes
this distinction particularly useful.
> 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.
That patch is, err, long. Is there any way you can break it into
distinct functional hunks to make review easier?