[patch][RFC] 160-bits bitmap_element

[Steven Bosscher]

Hello,

On a 64-bits host we leave 32 bits of each bitmap_element unused. And
actually, on a 32-bits host we do that too for GGC-allocated bitmaps
(due to alignment).

With this patch, we use those 32 bits by making BITMAP_WORD an
unsigned int (instead of unsigned long) and having 5 elts per
bitmap_element (instead of 2 or 4).

The effect is that computing the bit position gets more expensive.
Currently this only needs a div/mod by a power-of-two, but with this
patch it's a div/mod 5. But because most bitmaps are sparse in blocks,
bitmaps with 160 bits bitmap_elements have fewer searches. And I think
that in general the call overhead to the bitmap functions
(bitmap_bit_p/bitmap_set_bit are not inline functions, they're
relatively large) and the pointer chasing is more expensive than
requiring div/mod 5. Compile time for a set of cc1-i files doesn't
change, but compile time for the small test case of PR54146 goes down
by ~10%, and peak memory goes down a bit too (harder to measure so I
don't know exactly by how much).

Looking for your thoughts and comments,

Ciao!
Steven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bitmap_160.diff
Type: application/octet-stream
Size: 7341 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20120817/8463efaf/attachment.obj>