https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783
--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:c23db3ebb65ba357155be85ef56d037403eaee36 commit r14-10047-gc23db3ebb65ba357155be85ef56d037403eaee36 Author: Jakub Jelinek <ja...@redhat.com> Date: Sat Apr 20 00:13:49 2024 +0200 i386: Fix up *avx2_eq<mode>3 constraints [PR114783] The r14-4456 change (part of APX EGPR support) seems to have mistakenly changed in the @@ -16831,7 +16831,7 @@ (define_insn "*avx2_eq<mode>3" [(set (match_operand:VI_256 0 "register_operand" "=x") (eq:VI_256 (match_operand:VI_256 1 "nonimmediate_operand" "%x") - (match_operand:VI_256 2 "nonimmediate_operand" "xm")))] + (match_operand:VI_256 2 "nonimmediate_operand" "jm")))] "TARGET_AVX2 && !(MEM_P (operands[1]) && MEM_P (operands[2]))" "vpcmpeq<ssemodesuffix>\t{%2, %1, %0|%0, %1, %2}" [(set_attr "type" "ssecmp") hunk the xm constraint to jm, while in many other spots it changed correctly xm to xjm. The instruction doesn't require the last operand to be in memory, it can handle 3 256-bit registers just fine, just it is a VEX only encoded instruction and so can't allow APX EGPR regs in the memory operand. The following patch fixes it, so that we don't force one of the == operands into memory all the time. 2024-04-20 Jakub Jelinek <ja...@redhat.com> PR target/114783 * config/i386/sse.md (*avx2_eq<mode>3): Change last operand's constraint from "jm" to "xjm". * gcc.target/i386/avx2-pr114783.c: New test.
