[Bug target/92865] [10 Regression] error: unrecognizable insn: in extract_insn, at recog.c:2294 since r279107
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92865 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug target/92865] [10 Regression] error: unrecognizable insn: in extract_insn, at recog.c:2294 since r279107
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92865 --- Comment #7 from liuhongt at gcc dot gnu.org --- Author: liuhongt Date: Wed Dec 11 08:06:06 2019 New Revision: 279214 URL: https://gcc.gnu.org/viewcvs?rev=279214&root=gcc&view=rev Log: Fix unrecognizable insn of pr92865. gcc/ PR target/92865 * config/i386/i386-expand.c (ix86_valid_mask_cmp_mode): Enable integer mask cmov when available even with TARGET_XOP. gcc/testsuite * gcc.target/i386/pr92865-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr92865-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-expand.c trunk/gcc/testsuite/ChangeLog
[Bug target/92865] [10 Regression] error: unrecognizable insn: in extract_insn, at recog.c:2294 since r279107
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92865
--- Comment #6 from Hongtao.liu ---
The missing point of my patch is for 512-bit vector compare, integer mask
vector compare still should be used even with target_xop, that's the root cause
of this issue.
Refer to this part.
---
- if (GET_MODE_SIZE (cmp_ops_mode) == 64)
+ if (ix86_valid_mask_cmp_mode (cmp_ops_mode))
{
unsigned int nbits = GET_MODE_NUNITS (cmp_ops_mode);
- cmp_mode = int_mode_for_size (nbits, 0).require ();
maskcmp = true;
+ cmp_mode = nbits > 8 ? int_mode_for_size (nbits, 0).require () :
E_QImode;
}
else
cmp_mode = cmp_ops_mode;
@@ -3461,37 +3484,6 @@ ix86_expand_sse_cmp (rtx dest, enum rtx_code code, rtx
cmp_op0, rtx cmp_op1,
|| (op_false && reg_overlap_mentioned_p (dest, op_false)))
dest = gen_reg_rtx (maskcmp ? cmp_mode : mode);
- /* Compare patterns for int modes are unspec in AVX512F only. */
- if (maskcmp && (code == GT || code == EQ))
-{
- rtx (*gen)(rtx, rtx, rtx);
-
- switch (cmp_ops_mode)
- {
- case E_V64QImode:
- gcc_assert (TARGET_AVX512BW);
- gen = code == GT ? gen_avx512bw_gtv64qi3 : gen_avx512bw_eqv64qi3_1;
- break;
- case E_V32HImode:
- gcc_assert (TARGET_AVX512BW);
- gen = code == GT ? gen_avx512bw_gtv32hi3 : gen_avx512bw_eqv32hi3_1;
- break;
- case E_V16SImode:
- gen = code == GT ? gen_avx512f_gtv16si3 : gen_avx512f_eqv16si3_1;
- break;
- case E_V8DImode:
- gen = code == GT ? gen_avx512f_gtv8di3 : gen_avx512f_eqv8di3_1;
- break;
- default:
- gen = NULL;
- }
-
- if (gen)
- {
- emit_insn (gen (dest, cmp_op0, cmp_op1));
- return dest;
- }
-}
x = gen_rtx_fmt_ee (code, cmp_mode, cmp_op0, cmp_op1);
if (cmp_mode != mode && !maskcmp)
-
[Bug target/92865] [10 Regression] error: unrecognizable insn: in extract_insn, at recog.c:2294 since r279107
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92865
--- Comment #5 from Hongtao.liu ---
(In reply to Richard Biener from comment #4)
> (In reply to Hongtao.liu from comment #3)
> > Since TARGET_XOP only supports 128-bit vector compare,
> > ix86_valid_mask_cmp_mode should also handle 256/512-bit vector compare when
> > avx512f is avalable.
> >
> >
> > untested patch
> >
> > @@ -3428,7 +3428,7 @@ static bool
> > ix86_valid_mask_cmp_mode (machine_mode mode)
> > {
> >/* XOP has its own vector conditional movement. */
> > - if (TARGET_XOP)
> > + if (TARGET_XOP && GET_MODE_SIZE (mode) == 128)
> > return false;
>
> Shouldn't we do sth like TARGET_XOP && !TARGET_AVX512F instead? That is
> maybe simply elide that check completely, not sure why it was added.
True, thanks
>
> >/* AVX512F is needed for mask operation. */
> >
> > I'll add some testcase later.
[Bug target/92865] [10 Regression] error: unrecognizable insn: in extract_insn, at recog.c:2294 since r279107
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92865
--- Comment #4 from Richard Biener ---
(In reply to Hongtao.liu from comment #3)
> Since TARGET_XOP only supports 128-bit vector compare,
> ix86_valid_mask_cmp_mode should also handle 256/512-bit vector compare when
> avx512f is avalable.
>
>
> untested patch
>
> @@ -3428,7 +3428,7 @@ static bool
> ix86_valid_mask_cmp_mode (machine_mode mode)
> {
>/* XOP has its own vector conditional movement. */
> - if (TARGET_XOP)
> + if (TARGET_XOP && GET_MODE_SIZE (mode) == 128)
> return false;
Shouldn't we do sth like TARGET_XOP && !TARGET_AVX512F instead? That is
maybe simply elide that check completely, not sure why it was added.
>/* AVX512F is needed for mask operation. */
>
> I'll add some testcase later.
[Bug target/92865] [10 Regression] error: unrecognizable insn: in extract_insn, at recog.c:2294 since r279107
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92865
--- Comment #3 from Hongtao.liu ---
Since TARGET_XOP only supports 128-bit vector compare, ix86_valid_mask_cmp_mode
should also handle 256/512-bit vector compare when avx512f is avalable.
untested patch
@@ -3428,7 +3428,7 @@ static bool
ix86_valid_mask_cmp_mode (machine_mode mode)
{
/* XOP has its own vector conditional movement. */
- if (TARGET_XOP)
+ if (TARGET_XOP && GET_MODE_SIZE (mode) == 128)
return false;
/* AVX512F is needed for mask operation. */
I'll add some testcase later.
[Bug target/92865] [10 Regression] error: unrecognizable insn: in extract_insn, at recog.c:2294 since r279107
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92865 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |liuhongt at gcc dot gnu.org Summary|[10 Regression] error: |[10 Regression] error: |unrecognizable insn: in |unrecognizable insn: in |extract_insn, at|extract_insn, at |recog.c:2294 since |recog.c:2294 since r279107 --- Comment #2 from Martin Liška --- Yes, I can confirm that it's caused by your commit.
