[Bug tree-optimization/64434] [5 Regression] Performance regression after operand canonicalization (r216728).

rguenther at suse dot de gcc-bugzilla@gcc.gnu.org
Mon Dec 29 17:08:00 GMT 2014


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On December 29, 2014 5:56:25 PM CET, ysrumyan at gmail dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
>
>--- Comment #8 from Yuri Rumyantsev <ysrumyan at gmail dot com> ---
>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.
>
>Hope it will help you to understand the problem.

This is essentially a scheduling issue (and thus also related to TER).  I
played with the idea of a SSA life-range reducing BB scheduling without much
success.  The trick of swapping operands to expand the expensive one first
sounds good to me.

>2014-12-29 19:36 GMT+03:00 hjl.tools at gmail dot com
><gcc-bugzilla@gcc.gnu.org>:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434
>>
>> --- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
>> r216728 generates much longer code sequences.  Where does it come
>from?
>> Does -m64 also generate longer code sequences?
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.



More information about the Gcc-bugs mailing list