Re: More alloca patches

[Michael Meissner <meissner at cygnus dot com>]

On Mon, Nov 01, 1999 at 04:14:28PM -0800, Richard Henderson wrote:
> On Mon, Nov 01, 1999 at 04:20:23PM -0700, Mark P. Mitchell wrote:
> > 	* bitmap.h (BITMAP_XMALLOC): New macro.
> 
> I don't think this is the right approach here.  We're allocating 
> 3 words which should just IMO be allocated on the stack as normal
> local storage.
> 
> I don't think it's that difficult interface-wise to do something like
> 
> > !   uid_volatile = BITMAP_XMALLOC ();
> 
>    bitmap_head uid_volatile_head;
>    uid_volatile = bitmap_initialize (&uid_volatile_head);
> 
> I think what we're currently doing is being over-general for no
> visible benefit.
> 
> Michael, you originally wrote this stuff, did you have a particular
> reason for this method?

I was trying to keep the same allocation method as the code it was replacing.
Ie, code that used alloca before would continue to use alloca, ditto for
obstacks and xmalloc Ideally, now that we are doing garbage collection, the
bitmaps should garbage collected like the rtl.  At the moment there are only 3
uses of bitmap's (compared to the 22 uses of sbitmap's and 52 uses of
HARD_REG_SET's).

It would be an interesting study to see if there are places that use sbitmaps
that would benifit from the space reductions of bitmaps, and conversly places
that use bitmaps that are dense and would be sped up/use less space to be
converted to sbitmaps.  It also would be useful to keep track of how much
memory goes to trees, rtl, bitmaps, etc.

Also note that the biggest (spacewise at least) user of bitmaps (global.c and
reload{,1}.c using the tables created by global.c) doesn't use either sbitmaps
or bitmaps and rolls its own bit access mechanism.  I had global/reload
converted at one point to use bitmaps, but needed to revert the code at one
point for an unrelated reason before I did timing/memory studies to see if it
would help.  I think global should definately be converted to use sbitmap's at
least, and preferably bitmap's if the speed hit isn't too bad, and the space
savings are great.

-- 
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com	phone: 978-486-9304	fax: 978-692-4482