https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #7) > I think the difference is that the older flush_ssaname_freelist loop added > the SSA_NAMEs from FREE_SSANAMES_QUEUE (cfun) in reverse order, i.e. it > first pushed the last SSA_NAME from FREE_SSANAMES_QUEUE (cfun), then the one > before that and so on until the first one, while the splice version pushes > them in the order they appear. The new one is closer to the > pre-FREE_SSANAMES_QUEUE behavior, last SSA_NAME to be freed gets reused > first, the r228667 behavior has been very weird, it would try to reuse first > the oldest SSA_NAME freed since the one before last flush_ssaname_freelist > call, until the newest such SSA_NAME, then continue with the even older ones > etc. > That said, on CoreMark with the options you've provided I don't see any > difference in core_state_transition, nor in calc_func, but on > core_list_join.c see lots of changes in other functions (core_list_mergesort > and its constprop.2 variant). I'd argue that ideally we'd want to re-use SSA names in SSA_NAME_VERSION order to make ssa_names () dense. And we'd release the "tail" to GC. So as we now have two vectors for free SSA names we could as well keep free_ssanames sorted, sort free_ssanames_queue and then merge them appropriately... (sort them in reverse order so we can still pop() from the free vector)
