https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vmakarov at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In particular, reverting the:
--- gcc/config/i386/i386.md 2019-12-11 10:48:51.787820841 +0100
+++ gcc/config/i386/i386.md 2019-12-09 19:50:24.604955118 +0100
@@ -9223,10 +9223,10 @@
})
(define_insn "*<code><mode>_1"
- [(set (match_operand:SWI248 0 "nonimmediate_operand" "=r,rm")
+ [(set (match_operand:SWI248 0 "nonimmediate_operand" "=rm,r")
(any_or:SWI248
(match_operand:SWI248 1 "nonimmediate_operand" "%0,0")
- (match_operand:SWI248 2 "<general_operand>" "<g>,r<i>")))
+ (match_operand:SWI248 2 "<general_operand>" "r<i>,m")))
(clobber (reg:CC FLAGS_REG))]
"ix86_binary_operator_ok (<CODE>, <MODE>mode, operands)"
"<logic>{<imodesuffix>}\t{%2, %0|%0, %2}"
change fixes it. I admit I have no idea why. It is true that the operands are
commutative, so RA can choose whether to put the constant or what used to be in
xmm0 into the destination register, previously it chose what results in better
code by putting the constant into the instruction and xmm0 moved into a GPR,
now it spills xmm0 instead, puts the constant into the destination register and
uses a memory operand. The above mentioned commit changed this for commutative
operands in several spots.
