https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116285
--- Comment #3 from Sam James <sjames at gcc dot gnu.org> --- (In reply to Andi Kleen from comment #2) > push_to_top_level is about 5% and seems to do a lot of list walking of > different scopes. Maybe a better data structure like a vector for the scopes > would help. PR64500 covers this "now". > > On my skylake it appears to be primarily Frontend Bound due to large code, > so you might get a slight improvement by using a profile feedback built host > compiler that does hot cold code splitting. > > 3+% is GC so you could get some boost by increasing the GC limits to GC less > often. Try playing with --param ggc-min-expand and --param ggc-min-heapsize > This is a good idea. Thanks. > 0.94% of the cycles are iterative_hash, so you might get another slight > improvement from https://github.com/andikleen/gcc/commits/rapidhash-1 > which switches the hash function to something more modern > (still looking for supporting data that it actually helps) I'll try to give it a go some time (not immediately), I just need to set something up so I can properly measure it across package builds, not sure how yet (maybe pass -time for each build).
