https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
--- Comment #13 from Jeffrey A. Law <law at redhat dot com> --- Stabilizing the sort is just one piece in the problem. SSA_NAME_VERSIONs are also used as partition numbers. That doesn't seem to impact code generation (so far), but it does make dump comparisons bloody difficult to really analyze. That's what really got me thinking about this problem -- the fact that changes in the version #s not only affect code generation, but they make it orders of magnitude harder to evaluate whether or not stabilizing the sort is all that's needed to address the performance concerns due to gratutious changes in the dump files. The result of those ponderings was the idea that changing SSA_NAME_VERSIONs should have zero impact on the code we generate. We should be able to hand out names in a totally arbitrary order and ultimately get the same assembly code. Reality is somewhat different. Consider that in various places we canonicalize expression operands based on SSA_NAME_VERSIONs. Those can and will get different code based on SSA_NAME_VERSIONs in use. ie if (a_1 == b_2) if (a_2 == b_1) Should generate the same assembly code, but won't because the second will get canonicalized into if (b_1 == a_2) And when we convert that to RTL, it'll generate different code than the original a_1 == b_2 version. Similar situations occur due to canonicalization that happens during tree-ssa-reassoc and almost certainly other places. It's pervasive enough that the goal of "no change in assembly output due to SSA_NAME_VERSION changes" may not be attainable in the immediate future. Coming back to 64058 and 68654, it's not clear yet if just stabilizing the sort is sufficient. I'm still evaluating that. FWIW, I've got a variant that just stabilizes the sort with just an index we record as we find a potential coalescing pair. That's pretty trivial. I started down another path where I added a level of indirection between the SSA_NAME_VERSION and the associated partition maps. My worry with the latter is interactions with tree-ssa-live.c.
