https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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).
