[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