https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119482
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2025-04-02
--- Comment #14 from Andrew Pinski <pinskia 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)
bitmap_element right now has 2 pointers and one 32bit field (plus the bits).
so sizeof(bitmap_element) (without the bits) in bits is 96.
So there is at least 32bits of padding too.
r0-47360-g72e42e26cb760d changed it from being always 2 HOST_WIDE_INT to always
being 128 and unsigned long; but that didn't change any LP64 target (only maybe
LLP64 target aka windows).
Can you do some print out of how many bits are normally used for bitmaps? Maybe
run the whole testsuite with the extra instrumentation. This will prove
increasing it.
Also for this testcase where are the large bitmaps allocated? Is it RTL DF? or
RA?
