This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [bitmap memory]: Allocation part 2


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?
Unknown.

> 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?

jeff  



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]