https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119482
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to ak from comment #13) > This patch gives another 23% speedup due to reducing time handling the > linked lists for lazy bitmaps. Probably there is more tuning potential in > bitmaps > (most of the top 10 hot functions are bitmap related) > > The patch actually saves memory too: > > $ /usr/bin/time --format 'time %E maxrss %MK' ../obj-fast/gcc/cc1plus-bitmap > -std=gnu++20 -O2 pr119482.cc -quiet -w > time 0:43.19 maxrss 854920K > $ /usr/bin/time --format 'time %E maxrss %MK' > ../obj-fast/gcc/cc1plus-large-bitmap -std=gnu++20 -O2 pr119482.cc -quiet -w > time 0:35.96 maxrss 788424K > > -8% memory savings. I guess this means the access patterns are actually not > that > sparse. Note this will be bad for sparse access patterns which is what these bitmaps are for. Depending on how the bitmaps in question are used there's the possibility to use a tree instead of a linked list of elements via bitmap_tree_view () (but no bulk/iteration possible then). > diff --git a/gcc/bitmap.h b/gcc/bitmap.h > index 4a73ccdba794..a0a5098a25da 100644 > --- a/gcc/bitmap.h > +++ b/gcc/bitmap.h > @@ -283,7 +283,7 @@ typedef unsigned long BITMAP_WORD; > /* Number of words to use for each element in the linked list. */ > > #ifndef BITMAP_ELEMENT_WORDS > -#define BITMAP_ELEMENT_WORDS ((128 + BITMAP_WORD_BITS - 1) / > BITMAP_WORD_BITS) > +#define BITMAP_ELEMENT_WORDS ((512 + BITMAP_WORD_BITS - 1) / > BITMAP_WORD_BITS) > #endif > > /* Number of bits in each actual element of a bitmap. */
