Replacing bitmap.[ch]

[Daniel Berlin <dan at cgsoftware dot com>]

I've got a replacement for bitmap.[ch] (Backed with splay trees, and
using sbitmap's for the nodes, rather than rewrite all the operations
on bits like our current bitmap.[ch] does), that is more efficient in
both space and time, except, it doesn't have all the ops in some cases
(in terms of sbitmap.h being all the ops, which bitmap can't claim
either, but the bitmap.[ch] replacement can almost claim)
Is this a requirement before i go about submitting it as a bitmap
replacement?

In particular, it doesn't have XOR, IOR_COMPL, or simple
not.

It doesn't have simple not because that would change a sparse bitmap
into a dense one, and if you are going to do that, i'd rather provide
an ebitmap (for lack of a better term, since it hasn't replaced bitmap
yet) to sbitmap conversion that let you say if you wanted the
complement or not.
I assume this is why we have no bitmap_not function.

XOR is only used in one place, in flow.c (which seems to change every
day, according to stan), and it's in a verification function
(verify_local_live_at_start). However, if somebody thinks it's useful,
I'll happily implement it.

IOR_COMPL falls under the same category as simple not. Except it's
worse. It'll make at least as dense a set, and possibly more dense
(since it's the or of a complemented sparse set and a sparse set).

Its also, unsurprisingly, not used anywhere.

So, would it be considered "incomplete" if i didn't include IOR_COMPL,
XOR,  and simple not in a bitmap.[ch] replacement?

I'm going for something functional enough and fast enough to be used
as a replacement for sbitmaps in things like LCM/GCSE without more work
than renaming calls.  So the less bitmap operations i have to sit here and
think of how to optimize, the better.


-- 
"I spilled spot remover on my dog.  He's gone now.
"-Steven Wright