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.