[Bug target/105338] [12 Regression] Regression: jump or cmove generated for pattern (x ? CST : 0)
cvs-commit at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Sat Apr 23 08:26:16 GMT 2022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105338
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:1ceddd7497e15d262ead6f673f8f5ce79dd63714
commit r12-8233-g1ceddd7497e15d262ead6f673f8f5ce79dd63714
Author: Jakub Jelinek <jakub@redhat.com>
Date: Sat Apr 23 10:25:31 2022 +0200
i386: Improve ix86_expand_int_movcc [PR105338]
The following testcase regressed on x86_64 on the trunk, due to some GIMPLE
pass changes (r12-7687) we end up an *.optimized dump difference of:
@@ -8,14 +8,14 @@ int foo (int i)
<bb 2> [local count: 1073741824]:
if (i_2(D) != 0)
- goto <bb 4>; [35.00%]
+ goto <bb 3>; [35.00%]
else
- goto <bb 3>; [65.00%]
+ goto <bb 4>; [65.00%]
- <bb 3> [local count: 697932184]:
+ <bb 3> [local count: 375809640]:
<bb 4> [local count: 1073741824]:
- # iftmp.0_1 = PHI <5(2), i_2(D)(3)>
+ # iftmp.0_1 = PHI <5(3), i_2(D)(2)>
return iftmp.0_1;
}
and similarly for the other functions. That is functionally equivalent and
there is no canonical form for those. The reason for i_2(D) in the PHI
argument as opposed to 0 is the uncprop pass, that is in many cases
beneficial for expansion as we don't need to load the value into some
pseudo
in one of the if blocks.
Now, for the 11.x ordering we have the pseudo = i insn in the extended
basic
block (it comes first) and so forwprop1 undoes what uncprop does by
propagating constant 0 there. But for the 12.x ordering, the extended
basic
block contains pseudo = 5 and pseudo = i is in the other bb and so fwprop1
doesn't change it.
During the ce1 pass, we attempt to emit a conditional move and we have very
nice code for the cases where both last operands of ?: are constant, and
yet
another for !TARGET_CMOVE if at least one of them is.
The following patch will undo the uncprop behavior during
ix86_expand_int_movcc, but just for those spots that can benefit from both
or at least one operands being constant, leaving the pure cmov case as is
(because then it is useful not to have to load a constant into a pseudo
as it already is in one). We can do that in the
op0 == op1 ? op0 : op3
or
op0 != op1 ? op2 : op0
cases if op1 is a CONST_INT by pretending it is
op0 == op1 ? op1 : op3
or
op0 != op1 ? op2 : op1
2022-04-23 Jakub Jelinek <jakub@redhat.com>
PR target/105338
* config/i386/i386-expand.cc (ix86_expand_int_movcc): Handle
op0 == cst1 ? op0 : op3 like op0 == cst1 ? cst1 : op3 for the
non-cmov
cases.
* gcc.target/i386/pr105338.c: New test.
More information about the Gcc-bugs
mailing list