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]

Common bitmap interface



I'd like to submit for review yet another bitmap implementation for
GCC.  Yes, GCC already has too many bitmap implementations but the
problem is that each implementation has its own interface.  What I
would like to see in GCC is a _single_ consistent bitmap interface
that allows us to bolt in a number of implementations; either
optimised for speed or storage, etc.

This patch is an attempt at producing a consistent bitmap interface to
replace the current sbitmap.h and bitmap.h interfaces and to provide a
mechanism where other bitmap implementations can be supported, such as
Dan Belin's ebitmap idea or dynamically resized bitmaps.  There are
many advantages from using a single interface, not only from the
maintainability of GCC but also in the peformance of GCC.  Ideally, I
would like to see us add heuristics that would help select the bitmap
implementation, say given some hints as to the size and density of the
bitmaps.

The approach I have used is for each implementation to provide a
vector of operations that the common interface calls.  The timing
tests I have performed to date show no additional penalty due to the
indirection, in fact it seems to run faster.

To test the new code I have changed sbitmap.h to be a wrapper to the
new interface and have replaced sbitmap.c.  The next stage would be to
redo bitmap.c and then to replace the sbitmap and bitmap interfaces
with the new interface. 

At this stage I'm canvassing for comments and suggestions for
improvements.  I'll knock up the ChangeLog entry if I get the green
light.


Michael.

Attachment: newbitset.patch.gz
Description: Binary data


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