https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
H.J. Lu <hjl.tools at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[5 Regression] Performance |[5 Regression] Performance |regression after operand |regression after operand |cannibalization (r216728). |canonicalization (r216728). --- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> --- (In reply to Yuri Rumyantsev from comment #8) > The issue is caused by operand canonicalization, i.e. there is special > operand odering for commutative operations to have the same > representation for a + b and b + a. If computation of second operand > requires more operations this may lead to live range increasing ( for > live variables computed by first operand). If we swap these operands > we get live range shrinking which is essential for 32-bit targets > having only few registers. > Are there any benefits for operand canonicalization for x86-64? Testcases in r216728 seems to indicate that it is a good thing to do. There may be a case where operand canonicalization even wins for x86.