[v2,9/9] x86: correct VFPCLASSP{S,D} operand size handling

Message ID 11f5cb95-9e6b-034b-5887-12d0d387fa8a@suse.com
State New
Headers show
Series
  • x86: operand size handling improvements
Related show

Commit Message

Jan Beulich Oct. 28, 2019, 8:10 a.m.
With AVX512VL disabled (e.g. when writing code for the Knights family
of processors) these insns aren't ambiguous when used with a memory
source, and hence should be accepted without suffix or operand size
specifier. When AVX512VL is enabled, to be consistent with this as
well as other ambiguous operand size handling it seems better to just
wanrn about the ambiguity in AT&T mode, and still default to 512-bit
operands (on the assumption that the code may have been written without
AVX512VL in mind yet).

gas/
2019-10-XX  Jan Beulich  <jbeulich@suse.com>

	* config/tc-i386.c (avx512): New (at file scope), moved from
	(check_VecOperands): ... here.
	(process_suffix): Add [XYZ]MMword operand size handling.
	* testsuite/gas/i386/noavx512-2.s, testsuite/gas/i386/noreg16.s,
	testsuite/gas/i386/noreg32.s, testsuite/gas/i386/noreg64.s: Add
	VFPCLASS tests.
	* testsuite/gas/i386/noavx512-2.l, testsuite/gas/i386/noreg16.d,
	testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.d,
	testsuite/gas/i386/noreg32.l, testsuite/gas/i386/noreg64.d,
	testsuite/gas/i386/noreg64.l: Adjust expectations.

opcodes/
2019-10-XX  Jan Beulich  <jbeulich@suse.com>

	* i386-opc.tbl (vfpclasspd, vfpclassps): Add Unspecified.
	* i386-tbl.h: Re-generate.

Comments

H.J. Lu Oct. 29, 2019, 7:16 p.m. | #1
On Mon, Oct 28, 2019 at 1:10 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> With AVX512VL disabled (e.g. when writing code for the Knights family

> of processors) these insns aren't ambiguous when used with a memory

> source, and hence should be accepted without suffix or operand size

> specifier. When AVX512VL is enabled, to be consistent with this as

> well as other ambiguous operand size handling it seems better to just

> wanrn about the ambiguity in AT&T mode, and still default to 512-bit

> operands (on the assumption that the code may have been written without

> AVX512VL in mind yet).


There is no need for this.   Memory size or suffix is always needed for them.

> gas/

> 2019-10-XX  Jan Beulich  <jbeulich@suse.com>

>

>         * config/tc-i386.c (avx512): New (at file scope), moved from

>         (check_VecOperands): ... here.

>         (process_suffix): Add [XYZ]MMword operand size handling.

>         * testsuite/gas/i386/noavx512-2.s, testsuite/gas/i386/noreg16.s,

>         testsuite/gas/i386/noreg32.s, testsuite/gas/i386/noreg64.s: Add

>         VFPCLASS tests.

>         * testsuite/gas/i386/noavx512-2.l, testsuite/gas/i386/noreg16.d,

>         testsuite/gas/i386/noreg16.l, testsuite/gas/i386/noreg32.d,

>         testsuite/gas/i386/noreg32.l, testsuite/gas/i386/noreg64.d,

>         testsuite/gas/i386/noreg64.l: Adjust expectations.

>

> opcodes/

> 2019-10-XX  Jan Beulich  <jbeulich@suse.com>

>

>         * i386-opc.tbl (vfpclasspd, vfpclassps): Add Unspecified.

>         * i386-tbl.h: Re-generate.

>





-- 
H.J.
Jan Beulich Oct. 30, 2019, 8:03 a.m. | #2
On 29.10.2019 20:16, H.J. Lu wrote:
> On Mon, Oct 28, 2019 at 1:10 AM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> With AVX512VL disabled (e.g. when writing code for the Knights family

>> of processors) these insns aren't ambiguous when used with a memory

>> source, and hence should be accepted without suffix or operand size

>> specifier. When AVX512VL is enabled, to be consistent with this as

>> well as other ambiguous operand size handling it seems better to just

>> wanrn about the ambiguity in AT&T mode, and still default to 512-bit

>> operands (on the assumption that the code may have been written without

>> AVX512VL in mind yet).

> 

> There is no need for this.   Memory size or suffix is always needed for them.


It is not - what you say (again) is your private opinion, not (afaict)
something based on some objective criteria. If I'm missing something
here, please clarify, but recall that we've been discussing this before.

Jan
H.J. Lu Oct. 30, 2019, 10:40 p.m. | #3
On Wed, Oct 30, 2019 at 1:03 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 29.10.2019 20:16, H.J. Lu wrote:

> > On Mon, Oct 28, 2019 at 1:10 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> With AVX512VL disabled (e.g. when writing code for the Knights family

> >> of processors) these insns aren't ambiguous when used with a memory

> >> source, and hence should be accepted without suffix or operand size

> >> specifier. When AVX512VL is enabled, to be consistent with this as

> >> well as other ambiguous operand size handling it seems better to just

> >> wanrn about the ambiguity in AT&T mode, and still default to 512-bit

> >> operands (on the assumption that the code may have been written without

> >> AVX512VL in mind yet).

> >

> > There is no need for this.   Memory size or suffix is always needed for them.

>

> It is not - what you say (again) is your private opinion, not (afaict)

> something based on some objective criteria. If I'm missing something

> here, please clarify, but recall that we've been discussing this before.

>


As I remembered, I didn't believe they should be treated differently,
depending on AVX512VL.  One should be able to tell what the operand
size is without checking if AVX512VL was disabled or not when the assembly
file was assembled.


-- 
H.J.
Jan Beulich Oct. 31, 2019, 9:39 a.m. | #4
On 30.10.2019 23:40,  H.J. Lu  wrote:
> On Wed, Oct 30, 2019 at 1:03 AM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 29.10.2019 20:16, H.J. Lu wrote:

>>> On Mon, Oct 28, 2019 at 1:10 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>

>>>> With AVX512VL disabled (e.g. when writing code for the Knights family

>>>> of processors) these insns aren't ambiguous when used with a memory

>>>> source, and hence should be accepted without suffix or operand size

>>>> specifier. When AVX512VL is enabled, to be consistent with this as

>>>> well as other ambiguous operand size handling it seems better to just

>>>> wanrn about the ambiguity in AT&T mode, and still default to 512-bit

>>>> operands (on the assumption that the code may have been written without

>>>> AVX512VL in mind yet).

>>>

>>> There is no need for this.   Memory size or suffix is always needed for them.

>>

>> It is not - what you say (again) is your private opinion, not (afaict)

>> something based on some objective criteria. If I'm missing something

>> here, please clarify, but recall that we've been discussing this before.

>>

> 

> As I remembered, I didn't believe they should be treated differently,

> depending on AVX512VL.  One should be able to tell what the operand

> size is without checking if AVX512VL was disabled or not when the assembly

> file was assembled.


Well - I understand this position of yours, but I can only repeat: To
me this is your personal preference, not an objective criteria. Let's
take PUSH/POP for comparison: Original 16-bit code may have been
written without the i386 in mind. Why would you enforce on people to
append W suffixes just because the assembler becomes i386 (and hence
32-bit operand) aware? An indeed - gas doesn't require suffixes here,
silently defaulting to the default size implied by the mode specified.
It's even more relaxed there - the defaults get used irrespective of
any .arch settings.

IOW I continue to think that it should be the programmer's choice
whether to imply CPU capability restrictions for their own code. It's
not like I'm forbidding the use of the suffix / operand size specifier
when none is actually needed.

Jan
H.J. Lu Oct. 31, 2019, 6:07 p.m. | #5
On Thu, Oct 31, 2019 at 2:39 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 30.10.2019 23:40,  H.J. Lu  wrote:

> > On Wed, Oct 30, 2019 at 1:03 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> On 29.10.2019 20:16, H.J. Lu wrote:

> >>> On Mon, Oct 28, 2019 at 1:10 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>

> >>>> With AVX512VL disabled (e.g. when writing code for the Knights family

> >>>> of processors) these insns aren't ambiguous when used with a memory

> >>>> source, and hence should be accepted without suffix or operand size

> >>>> specifier. When AVX512VL is enabled, to be consistent with this as

> >>>> well as other ambiguous operand size handling it seems better to just

> >>>> wanrn about the ambiguity in AT&T mode, and still default to 512-bit

> >>>> operands (on the assumption that the code may have been written without

> >>>> AVX512VL in mind yet).

> >>>

> >>> There is no need for this.   Memory size or suffix is always needed for them.

> >>

> >> It is not - what you say (again) is your private opinion, not (afaict)

> >> something based on some objective criteria. If I'm missing something

> >> here, please clarify, but recall that we've been discussing this before.

> >>

> >

> > As I remembered, I didn't believe they should be treated differently,

> > depending on AVX512VL.  One should be able to tell what the operand

> > size is without checking if AVX512VL was disabled or not when the assembly

> > file was assembled.

>

> Well - I understand this position of yours, but I can only repeat: To

> me this is your personal preference, not an objective criteria. Let's

> take PUSH/POP for comparison: Original 16-bit code may have been

> written without the i386 in mind. Why would you enforce on people to

> append W suffixes just because the assembler becomes i386 (and hence

> 32-bit operand) aware? An indeed - gas doesn't require suffixes here,

> silently defaulting to the default size implied by the mode specified.

> It's even more relaxed there - the defaults get used irrespective of

> any .arch settings.

>

> IOW I continue to think that it should be the programmer's choice

> whether to imply CPU capability restrictions for their own code. It's

> not like I'm forbidding the use of the suffix / operand size specifier

> when none is actually needed.

>


Assembler accepts all instructions by default.   Interpret an instruction
based on ISA doesn't buy much and may lead confusions.

-- 
H.J.
Jan Beulich Nov. 4, 2019, 10:21 a.m. | #6
On 31.10.2019 19:07,  H.J. Lu  wrote:
> On Thu, Oct 31, 2019 at 2:39 AM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 30.10.2019 23:40,  H.J. Lu  wrote:

>>> On Wed, Oct 30, 2019 at 1:03 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>

>>>> On 29.10.2019 20:16, H.J. Lu wrote:

>>>>> On Mon, Oct 28, 2019 at 1:10 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>

>>>>>> With AVX512VL disabled (e.g. when writing code for the Knights family

>>>>>> of processors) these insns aren't ambiguous when used with a memory

>>>>>> source, and hence should be accepted without suffix or operand size

>>>>>> specifier. When AVX512VL is enabled, to be consistent with this as

>>>>>> well as other ambiguous operand size handling it seems better to just

>>>>>> wanrn about the ambiguity in AT&T mode, and still default to 512-bit

>>>>>> operands (on the assumption that the code may have been written without

>>>>>> AVX512VL in mind yet).

>>>>>

>>>>> There is no need for this.   Memory size or suffix is always needed for them.

>>>>

>>>> It is not - what you say (again) is your private opinion, not (afaict)

>>>> something based on some objective criteria. If I'm missing something

>>>> here, please clarify, but recall that we've been discussing this before.

>>>>

>>>

>>> As I remembered, I didn't believe they should be treated differently,

>>> depending on AVX512VL.  One should be able to tell what the operand

>>> size is without checking if AVX512VL was disabled or not when the assembly

>>> file was assembled.

>>

>> Well - I understand this position of yours, but I can only repeat: To

>> me this is your personal preference, not an objective criteria. Let's

>> take PUSH/POP for comparison: Original 16-bit code may have been

>> written without the i386 in mind. Why would you enforce on people to

>> append W suffixes just because the assembler becomes i386 (and hence

>> 32-bit operand) aware? An indeed - gas doesn't require suffixes here,

>> silently defaulting to the default size implied by the mode specified.

>> It's even more relaxed there - the defaults get used irrespective of

>> any .arch settings.

>>

>> IOW I continue to think that it should be the programmer's choice

>> whether to imply CPU capability restrictions for their own code. It's

>> not like I'm forbidding the use of the suffix / operand size specifier

>> when none is actually needed.

>>

> 

> Assembler accepts all instructions by default.   Interpret an instruction

> based on ISA doesn't buy much and may lead confusions.


Yet _if_ someone cares to restrict the set of accepted insns to just
what they mean to target, then it'll be (at least) equally confusing
for the assembler to not accept an unambiguous (under the given
constraints) mnemonic. IOW I still don't understand why you object
to letting programmers decide what they prefer, and instead want to
"dictate" your view onto everyone.

Jan
H.J. Lu Nov. 4, 2019, 5:20 p.m. | #7
On Mon, Nov 4, 2019 at 2:21 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 31.10.2019 19:07,  H.J. Lu  wrote:

> > On Thu, Oct 31, 2019 at 2:39 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> On 30.10.2019 23:40,  H.J. Lu  wrote:

> >>> On Wed, Oct 30, 2019 at 1:03 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>

> >>>> On 29.10.2019 20:16, H.J. Lu wrote:

> >>>>> On Mon, Oct 28, 2019 at 1:10 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>>>

> >>>>>> With AVX512VL disabled (e.g. when writing code for the Knights family

> >>>>>> of processors) these insns aren't ambiguous when used with a memory

> >>>>>> source, and hence should be accepted without suffix or operand size

> >>>>>> specifier. When AVX512VL is enabled, to be consistent with this as

> >>>>>> well as other ambiguous operand size handling it seems better to just

> >>>>>> wanrn about the ambiguity in AT&T mode, and still default to 512-bit

> >>>>>> operands (on the assumption that the code may have been written without

> >>>>>> AVX512VL in mind yet).

> >>>>>

> >>>>> There is no need for this.   Memory size or suffix is always needed for them.

> >>>>

> >>>> It is not - what you say (again) is your private opinion, not (afaict)

> >>>> something based on some objective criteria. If I'm missing something

> >>>> here, please clarify, but recall that we've been discussing this before.

> >>>>

> >>>

> >>> As I remembered, I didn't believe they should be treated differently,

> >>> depending on AVX512VL.  One should be able to tell what the operand

> >>> size is without checking if AVX512VL was disabled or not when the assembly

> >>> file was assembled.

> >>

> >> Well - I understand this position of yours, but I can only repeat: To

> >> me this is your personal preference, not an objective criteria. Let's

> >> take PUSH/POP for comparison: Original 16-bit code may have been

> >> written without the i386 in mind. Why would you enforce on people to

> >> append W suffixes just because the assembler becomes i386 (and hence

> >> 32-bit operand) aware? An indeed - gas doesn't require suffixes here,

> >> silently defaulting to the default size implied by the mode specified.

> >> It's even more relaxed there - the defaults get used irrespective of

> >> any .arch settings.

> >>

> >> IOW I continue to think that it should be the programmer's choice

> >> whether to imply CPU capability restrictions for their own code. It's

> >> not like I'm forbidding the use of the suffix / operand size specifier

> >> when none is actually needed.

> >>

> >

> > Assembler accepts all instructions by default.   Interpret an instruction

> > based on ISA doesn't buy much and may lead confusions.

>

> Yet _if_ someone cares to restrict the set of accepted insns to just

> what they mean to target, then it'll be (at least) equally confusing

> for the assembler to not accept an unambiguous (under the given

> constraints) mnemonic. IOW I still don't understand why you object

> to letting programmers decide what they prefer, and instead want to

> "dictate" your view onto everyone.

>


Assemblers have been behaving this way for a long time.  I don't
think we should change it now.

-- 
H.J.
Jan Beulich Nov. 5, 2019, 7:46 a.m. | #8
On 04.11.2019 18:20,  H.J. Lu  wrote:
> On Mon, Nov 4, 2019 at 2:21 AM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 31.10.2019 19:07,  H.J. Lu  wrote:

>>> On Thu, Oct 31, 2019 at 2:39 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>

>>>> On 30.10.2019 23:40,  H.J. Lu  wrote:

>>>>> On Wed, Oct 30, 2019 at 1:03 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>

>>>>>> On 29.10.2019 20:16, H.J. Lu wrote:

>>>>>>> On Mon, Oct 28, 2019 at 1:10 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>>>

>>>>>>>> With AVX512VL disabled (e.g. when writing code for the Knights family

>>>>>>>> of processors) these insns aren't ambiguous when used with a memory

>>>>>>>> source, and hence should be accepted without suffix or operand size

>>>>>>>> specifier. When AVX512VL is enabled, to be consistent with this as

>>>>>>>> well as other ambiguous operand size handling it seems better to just

>>>>>>>> wanrn about the ambiguity in AT&T mode, and still default to 512-bit

>>>>>>>> operands (on the assumption that the code may have been written without

>>>>>>>> AVX512VL in mind yet).

>>>>>>>

>>>>>>> There is no need for this.   Memory size or suffix is always needed for them.

>>>>>>

>>>>>> It is not - what you say (again) is your private opinion, not (afaict)

>>>>>> something based on some objective criteria. If I'm missing something

>>>>>> here, please clarify, but recall that we've been discussing this before.

>>>>>>

>>>>>

>>>>> As I remembered, I didn't believe they should be treated differently,

>>>>> depending on AVX512VL.  One should be able to tell what the operand

>>>>> size is without checking if AVX512VL was disabled or not when the assembly

>>>>> file was assembled.

>>>>

>>>> Well - I understand this position of yours, but I can only repeat: To

>>>> me this is your personal preference, not an objective criteria. Let's

>>>> take PUSH/POP for comparison: Original 16-bit code may have been

>>>> written without the i386 in mind. Why would you enforce on people to

>>>> append W suffixes just because the assembler becomes i386 (and hence

>>>> 32-bit operand) aware? An indeed - gas doesn't require suffixes here,

>>>> silently defaulting to the default size implied by the mode specified.

>>>> It's even more relaxed there - the defaults get used irrespective of

>>>> any .arch settings.

>>>>

>>>> IOW I continue to think that it should be the programmer's choice

>>>> whether to imply CPU capability restrictions for their own code. It's

>>>> not like I'm forbidding the use of the suffix / operand size specifier

>>>> when none is actually needed.

>>>>

>>>

>>> Assembler accepts all instructions by default.   Interpret an instruction

>>> based on ISA doesn't buy much and may lead confusions.

>>

>> Yet _if_ someone cares to restrict the set of accepted insns to just

>> what they mean to target, then it'll be (at least) equally confusing

>> for the assembler to not accept an unambiguous (under the given

>> constraints) mnemonic. IOW I still don't understand why you object

>> to letting programmers decide what they prefer, and instead want to

>> "dictate" your view onto everyone.

>>

> 

> Assemblers have been behaving this way for a long time.  I don't

> think we should change it now.


I.e. bugs present for a long time shouldn't be fixed? Only ones
recently introduced should be?

Jan
H.J. Lu Nov. 6, 2019, 7:08 p.m. | #9
On Mon, Nov 4, 2019 at 11:46 PM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 04.11.2019 18:20,  H.J. Lu  wrote:

> > On Mon, Nov 4, 2019 at 2:21 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> On 31.10.2019 19:07,  H.J. Lu  wrote:

> >>> On Thu, Oct 31, 2019 at 2:39 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>

> >>>> On 30.10.2019 23:40,  H.J. Lu  wrote:

> >>>>> On Wed, Oct 30, 2019 at 1:03 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>>>

> >>>>>> On 29.10.2019 20:16, H.J. Lu wrote:

> >>>>>>> On Mon, Oct 28, 2019 at 1:10 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>>>>>

> >>>>>>>> With AVX512VL disabled (e.g. when writing code for the Knights family

> >>>>>>>> of processors) these insns aren't ambiguous when used with a memory

> >>>>>>>> source, and hence should be accepted without suffix or operand size

> >>>>>>>> specifier. When AVX512VL is enabled, to be consistent with this as

> >>>>>>>> well as other ambiguous operand size handling it seems better to just

> >>>>>>>> wanrn about the ambiguity in AT&T mode, and still default to 512-bit

> >>>>>>>> operands (on the assumption that the code may have been written without

> >>>>>>>> AVX512VL in mind yet).

> >>>>>>>

> >>>>>>> There is no need for this.   Memory size or suffix is always needed for them.

> >>>>>>

> >>>>>> It is not - what you say (again) is your private opinion, not (afaict)

> >>>>>> something based on some objective criteria. If I'm missing something

> >>>>>> here, please clarify, but recall that we've been discussing this before.

> >>>>>>

> >>>>>

> >>>>> As I remembered, I didn't believe they should be treated differently,

> >>>>> depending on AVX512VL.  One should be able to tell what the operand

> >>>>> size is without checking if AVX512VL was disabled or not when the assembly

> >>>>> file was assembled.

> >>>>

> >>>> Well - I understand this position of yours, but I can only repeat: To

> >>>> me this is your personal preference, not an objective criteria. Let's

> >>>> take PUSH/POP for comparison: Original 16-bit code may have been

> >>>> written without the i386 in mind. Why would you enforce on people to

> >>>> append W suffixes just because the assembler becomes i386 (and hence

> >>>> 32-bit operand) aware? An indeed - gas doesn't require suffixes here,

> >>>> silently defaulting to the default size implied by the mode specified.

> >>>> It's even more relaxed there - the defaults get used irrespective of

> >>>> any .arch settings.

> >>>>

> >>>> IOW I continue to think that it should be the programmer's choice

> >>>> whether to imply CPU capability restrictions for their own code. It's

> >>>> not like I'm forbidding the use of the suffix / operand size specifier

> >>>> when none is actually needed.

> >>>>

> >>>

> >>> Assembler accepts all instructions by default.   Interpret an instruction

> >>> based on ISA doesn't buy much and may lead confusions.

> >>

> >> Yet _if_ someone cares to restrict the set of accepted insns to just

> >> what they mean to target, then it'll be (at least) equally confusing

> >> for the assembler to not accept an unambiguous (under the given

> >> constraints) mnemonic. IOW I still don't understand why you object

> >> to letting programmers decide what they prefer, and instead want to

> >> "dictate" your view onto everyone.

> >>

> >

> > Assemblers have been behaving this way for a long time.  I don't

> > think we should change it now.

>

> I.e. bugs present for a long time shouldn't be fixed? Only ones

> recently introduced should be?

>


I don't think it is a problem to begin with.


-- 
H.J.

Patch

--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1757,6 +1757,8 @@  cpu_flags_and_not (i386_cpu_flags x, i38
   return x;
 }
 
+static const i386_cpu_flags avx512 = CPU_ANY_AVX512F_FLAGS;
+
 #define CPU_FLAGS_ARCH_MATCH		0x1
 #define CPU_FLAGS_64BIT_MATCH		0x2
 
@@ -5281,7 +5283,6 @@  check_VecOperands (const insn_template *
 {
   unsigned int op;
   i386_cpu_flags cpu;
-  static const i386_cpu_flags avx512 = CPU_ANY_AVX512F_FLAGS;
 
   /* Templates allowing for ZMMword as well as YMMword and/or XMMword for
      any one operand are implicity requiring AVX512VL support if the actual
@@ -6369,7 +6370,8 @@  process_suffix (void)
 
   if (!i.suffix)
     {
-      unsigned int suffixes;
+      unsigned int suffixes, evex = 0;
+      i386_cpu_flags cpu;
 
       suffixes = !i.tm.opcode_modifier.no_bsuf;
       if (!i.tm.opcode_modifier.no_wsuf)
@@ -6383,7 +6385,56 @@  process_suffix (void)
       if (flag_code == CODE_64BIT && !i.tm.opcode_modifier.no_qsuf)
 	suffixes |= 1 << 5;
 
-      /* Are multiple suffixes allowed?  */
+      /* For [XYZ]MMWORD operands inspect operand sizes.  */
+      cpu = cpu_flags_and (i.tm.cpu_flags, avx512);
+      if (!cpu_flags_all_zero (&cpu)
+	  && !i.broadcast)
+	{
+	  unsigned int op;
+
+	  for (op = 0; op < i.tm.operands; ++op)
+	    {
+	      if (!cpu_arch_flags.bitfield.cpuavx512vl)
+		{
+		  if (i.tm.operand_types[op].bitfield.ymmword)
+		    i.tm.operand_types[op].bitfield.xmmword = 0;
+		  if (i.tm.operand_types[op].bitfield.zmmword)
+		    i.tm.operand_types[op].bitfield.ymmword = 0;
+		  if (!i.tm.opcode_modifier.evex
+		      || i.tm.opcode_modifier.evex == EVEXDYN)
+		    i.tm.opcode_modifier.evex = EVEX512;
+		}
+
+	      if (i.tm.operand_types[op].bitfield.xmmword
+		  + i.tm.operand_types[op].bitfield.ymmword
+		  + i.tm.operand_types[op].bitfield.zmmword < 2)
+		continue;
+
+	      /* Any properly sized operand disambiguates the insn.  */
+	      if (i.types[op].bitfield.xmmword
+		  || i.types[op].bitfield.ymmword
+		  || i.types[op].bitfield.zmmword)
+		{
+		  suffixes &= ~(7 << 6);
+		  evex = 0;
+		  break;
+		}
+
+	      if ((i.flags[op] & Operand_Mem)
+		  && i.tm.operand_types[op].bitfield.unspecified)
+		{
+		  if (i.tm.operand_types[op].bitfield.xmmword)
+		    suffixes |= 1 << 6;
+		  if (i.tm.operand_types[op].bitfield.ymmword)
+		    suffixes |= 1 << 7;
+		  if (i.tm.operand_types[op].bitfield.zmmword)
+		    suffixes |= 1 << 8;
+		  evex = EVEX512;
+		}
+	    }
+	}
+
+      /* Are multiple suffixes / operand sizes allowed?  */
       if ((suffixes & (suffixes - 1))
 	  && !i.tm.opcode_modifier.defaultsize
 	  && !i.tm.opcode_modifier.ignoresize)
@@ -6408,6 +6459,8 @@  process_suffix (void)
 	    i.suffix = SHORT_MNEM_SUFFIX;
 	  else if ((i.tm.base_opcode | 8) == 0xfbe || i.tm.base_opcode == 0x63)
 	    /* handled below */;
+	  else if (evex)
+	    i.tm.opcode_modifier.evex = evex;
 	  else if (flag_code == CODE_16BIT)
 	    i.suffix = WORD_MNEM_SUFFIX;
 	  else if (!i.tm.opcode_modifier.no_lsuf)
--- a/gas/testsuite/gas/i386/noavx512-2.l
+++ b/gas/testsuite/gas/i386/noavx512-2.l
@@ -101,5 +101,10 @@  GAS LISTING .*
 [ 	]*50[ 	]+F5
 [ 	]*51[ 	]+\?\?\?\? 660F58F4 		addpd %xmm4, %xmm6
 [ 	]*52[ 	]+
-[ 	]*53[ 	]+\?\?\?\? 0F1F00   		\.p2align 4
+[ 	]*[1-9][0-9]*[ 	]+\?\?\?\? 62F3FD48 		vfpclasspd \$0, \(%eax\), %k0
+[ 	]*[1-9][0-9]*[ 	]+660000
+[ 	]*[1-9][0-9]*[ 	]+\?\?\?\? 62F37D48 		vfpclassps \$0, \(%eax\), %k0
+[ 	]*[1-9][0-9]*[ 	]+660000
+[ 	]*[1-9][0-9]*[ 	]+
+[ 	]*[1-9][0-9]*[ 	].*\.p2align 4
 #pass
--- a/gas/testsuite/gas/i386/noavx512-2.s
+++ b/gas/testsuite/gas/i386/noavx512-2.s
@@ -50,4 +50,7 @@ 
 	pabsb %xmm5, %xmm6
 	addpd %xmm4, %xmm6
 
+	vfpclasspd $0, (%eax), %k0
+	vfpclassps $0, (%eax), %k0
+
 	.p2align 4
--- a/gas/testsuite/gas/i386/noreg16.d
+++ b/gas/testsuite/gas/i386/noreg16.d
@@ -145,6 +145,8 @@  Disassembly of section .text:
  *[a-f0-9]+:	62 f1 7e 08 2a 07    	vcvtsi2ssl \(%bx\),%xmm0,%xmm0
  *[a-f0-9]+:	62 f1 7f 08 7b 07    	vcvtusi2sdl \(%bx\),%xmm0,%xmm0
  *[a-f0-9]+:	62 f1 7e 08 7b 07    	vcvtusi2ssl \(%bx\),%xmm0,%xmm0
+ *[a-f0-9]+:	62 f3 fd 48 66 07 00 	vfpclasspdz \$0x0,\(%bx\),%k0
+ *[a-f0-9]+:	62 f3 7d 48 66 07 00 	vfpclasspsz \$0x0,\(%bx\),%k0
  *[a-f0-9]+:	83 37 01             	xorw   \$0x1,\(%bx\)
  *[a-f0-9]+:	81 37 89 00          	xorw   \$0x89,\(%bx\)
  *[a-f0-9]+:	81 37 34 12          	xorw   \$0x1234,\(%bx\)
--- a/gas/testsuite/gas/i386/noreg16.l
+++ b/gas/testsuite/gas/i386/noreg16.l
@@ -113,6 +113,8 @@ 
 .*:[1-9][0-9]*: Warning: .* `sub'
 .*:[1-9][0-9]*: Warning: .* `test'
 .*:[1-9][0-9]*: Warning: .* `test'
+.*:[1-9][0-9]*: Warning: .* `vfpclasspd'
+.*:[1-9][0-9]*: Warning: .* `vfpclassps'
 .*:[1-9][0-9]*: Warning: .* `xor'
 .*:[1-9][0-9]*: Warning: .* `xor'
 .*:[1-9][0-9]*: Warning: .* `xor'
--- a/gas/testsuite/gas/i386/noreg16.s
+++ b/gas/testsuite/gas/i386/noreg16.s
@@ -139,6 +139,8 @@  noreg:
 	{evex} vcvtsi2ss (%bx), %xmm0, %xmm0
 	vcvtusi2sd (%bx), %xmm0, %xmm0
 	vcvtusi2ss (%bx), %xmm0, %xmm0
+	vfpclasspd $0, (%bx), %k0
+	vfpclassps $0, (%bx), %k0
 	xor	$1, (%bx)
 	xor	$0x89, (%bx)
 	xor	$0x1234, (%bx)
--- a/gas/testsuite/gas/i386/noreg32.d
+++ b/gas/testsuite/gas/i386/noreg32.d
@@ -154,6 +154,8 @@  Disassembly of section .text:
  *[a-f0-9]+:	62 f1 7e 08 2a 00    	vcvtsi2ssl \(%eax\),%xmm0,%xmm0
  *[a-f0-9]+:	62 f1 7f 08 7b 00    	vcvtusi2sdl \(%eax\),%xmm0,%xmm0
  *[a-f0-9]+:	62 f1 7e 08 7b 00    	vcvtusi2ssl \(%eax\),%xmm0,%xmm0
+ *[a-f0-9]+:	62 f3 fd 48 66 00 00 	vfpclasspdz \$0x0,\(%eax\),%k0
+ *[a-f0-9]+:	62 f3 7d 48 66 00 00 	vfpclasspsz \$0x0,\(%eax\),%k0
  *[a-f0-9]+:	83 30 01             	xorl   \$0x1,\(%eax\)
  *[a-f0-9]+:	81 30 89 00 00 00    	xorl   \$0x89,\(%eax\)
  *[a-f0-9]+:	81 30 34 12 00 00    	xorl   \$0x1234,\(%eax\)
--- a/gas/testsuite/gas/i386/noreg32.l
+++ b/gas/testsuite/gas/i386/noreg32.l
@@ -122,6 +122,8 @@ 
 .*:[1-9][0-9]*: Warning: .* `test'
 .*:[1-9][0-9]*: Warning: .* `test'
 .*:[1-9][0-9]*: Warning: .* `test'
+.*:[1-9][0-9]*: Warning: .* `vfpclasspd'
+.*:[1-9][0-9]*: Warning: .* `vfpclassps'
 .*:[1-9][0-9]*: Warning: .* `xor'
 .*:[1-9][0-9]*: Warning: .* `xor'
 .*:[1-9][0-9]*: Warning: .* `xor'
--- a/gas/testsuite/gas/i386/noreg32.s
+++ b/gas/testsuite/gas/i386/noreg32.s
@@ -147,6 +147,8 @@  noreg:
 	{evex} vcvtsi2ss (%eax), %xmm0, %xmm0
 	vcvtusi2sd (%eax), %xmm0, %xmm0
 	vcvtusi2ss (%eax), %xmm0, %xmm0
+	vfpclasspd $0, (%eax), %k0
+	vfpclassps $0, (%eax), %k0
 	xor	$1, (%eax)
 	xor	$0x89, (%eax)
 	xor	$0x1234, (%eax)
--- a/gas/testsuite/gas/i386/noreg64.d
+++ b/gas/testsuite/gas/i386/noreg64.d
@@ -157,6 +157,8 @@  Disassembly of section .text:
  *[a-f0-9]+:	62 61 7e 08 2a 38    	vcvtsi2ssl \(%rax\),%xmm0,%xmm31
  *[a-f0-9]+:	62 f1 7f 08 7b 00    	vcvtusi2sdl \(%rax\),%xmm0,%xmm0
  *[a-f0-9]+:	62 f1 7e 08 7b 00    	vcvtusi2ssl \(%rax\),%xmm0,%xmm0
+ *[a-f0-9]+:	62 f3 fd 48 66 00 00 	vfpclasspdz \$0x0,\(%rax\),%k0
+ *[a-f0-9]+:	62 f3 7d 48 66 00 00 	vfpclasspsz \$0x0,\(%rax\),%k0
  *[a-f0-9]+:	83 30 01             	xorl   \$0x1,\(%rax\)
  *[a-f0-9]+:	81 30 89 00 00 00    	xorl   \$0x89,\(%rax\)
  *[a-f0-9]+:	81 30 34 12 00 00    	xorl   \$0x1234,\(%rax\)
--- a/gas/testsuite/gas/i386/noreg64.l
+++ b/gas/testsuite/gas/i386/noreg64.l
@@ -134,6 +134,8 @@ 
 .*:[1-9][0-9]*: Warning: .* `vcvtsi2ss'
 .*:[1-9][0-9]*: Warning: .* `vcvtusi2sd'
 .*:[1-9][0-9]*: Warning: .* `vcvtusi2ss'
+.*:[1-9][0-9]*: Warning: .* `vfpclasspd'
+.*:[1-9][0-9]*: Warning: .* `vfpclassps'
 .*:[1-9][0-9]*: Warning: .* `xor'
 .*:[1-9][0-9]*: Warning: .* `xor'
 .*:[1-9][0-9]*: Warning: .* `xor'
--- a/gas/testsuite/gas/i386/noreg64.s
+++ b/gas/testsuite/gas/i386/noreg64.s
@@ -150,6 +150,8 @@  noreg:
 	vcvtsi2ss (%rax), %xmm0, %xmm31
 	vcvtusi2sd (%rax), %xmm0, %xmm0
 	vcvtusi2ss (%rax), %xmm0, %xmm0
+	vfpclasspd $0, (%rax), %k0
+	vfpclassps $0, (%rax), %k0
 	xor	$1, (%rax)
 	xor	$0x89, (%rax)
 	xor	$0x1234, (%rax)
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -4474,12 +4474,12 @@  vextracti64x2, 3, 0x6639, None, 1, CpuAV
 vinsertf64x2, 4, 0x6618, None, 1, CpuAVX512DQ, Modrm|Masking=3|VexOpcode=2|VexVVVV=1|VexW=2|Disp8MemShift=4|CheckRegSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm8, RegXMM|Unspecified|BaseIndex, RegYMM|RegZMM, RegYMM|RegZMM }
 vinserti64x2, 4, 0x6638, None, 1, CpuAVX512DQ, Modrm|Masking=3|VexOpcode=2|VexVVVV=1|VexW=2|Disp8MemShift=4|CheckRegSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm8, RegXMM|Unspecified|BaseIndex, RegYMM|RegZMM, RegYMM|RegZMM }
 
-vfpclasspd, 3, 0x6666, None, 1, CpuAVX512DQ, Modrm|Masking=2|VexOpcode=2|VexW=2|Broadcast|Disp8ShiftVL|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm8, RegXMM|RegYMM|RegZMM|Qword|BaseIndex, RegMask }
+vfpclasspd, 3, 0x6666, None, 1, CpuAVX512DQ, Modrm|Masking=2|VexOpcode=2|VexW=2|Broadcast|Disp8ShiftVL|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm8, RegXMM|RegYMM|RegZMM|Qword|Unspecified|BaseIndex, RegMask }
 vfpclasspdz, 3, 0x6666, None, 1, CpuAVX512DQ, Modrm|EVex=1|Masking=2|VexOpcode=2|VexW=2|Broadcast|Disp8MemShift=6|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm8, RegZMM|Qword|Unspecified|BaseIndex, RegMask }
 vfpclasspdx, 3, 0x6666, None, 1, CpuAVX512DQ|CpuAVX512VL, Modrm|EVex=2|Masking=2|VexOpcode=2|VexW=2|Broadcast|Disp8MemShift=4|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm8, RegXMM|Qword|Unspecified|BaseIndex, RegMask }
 vfpclasspdy, 3, 0x6666, None, 1, CpuAVX512DQ|CpuAVX512VL, Modrm|EVex=3|Masking=2|VexOpcode=2|VexW=2|Broadcast|Disp8MemShift=5|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm8, RegYMM|Qword|Unspecified|BaseIndex, RegMask }
 
-vfpclassps, 3, 0x6666, None, 1, CpuAVX512DQ, Modrm|Masking=2|VexOpcode=2|VexW=1|Broadcast|Disp8ShiftVL|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm8, RegXMM|RegYMM|RegZMM|Dword|BaseIndex, RegMask }
+vfpclassps, 3, 0x6666, None, 1, CpuAVX512DQ, Modrm|Masking=2|VexOpcode=2|VexW=1|Broadcast|Disp8ShiftVL|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm8, RegXMM|RegYMM|RegZMM|Dword|Unspecified|BaseIndex, RegMask }
 vfpclasspsz, 3, 0x6666, None, 1, CpuAVX512DQ, Modrm|EVex=1|Masking=2|VexOpcode=2|VexW=1|Broadcast|Disp8MemShift=6|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm8, RegZMM|Dword|Unspecified|BaseIndex, RegMask }
 vfpclasspsx, 3, 0x6666, None, 1, CpuAVX512DQ|CpuAVX512VL, Modrm|EVex=2|Masking=2|VexOpcode=2|VexW=1|Broadcast|Disp8MemShift=4|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm8, RegXMM|Dword|Unspecified|BaseIndex, RegMask }
 vfpclasspsy, 3, 0x6666, None, 1, CpuAVX512DQ|CpuAVX512VL, Modrm|EVex=3|Masking=2|VexOpcode=2|VexW=1|Broadcast|Disp8MemShift=5|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm8, RegYMM|Dword|Unspecified|BaseIndex, RegMask }