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

Message ID 9f42a228-02b5-ace4-fbb7-0898b3d973d3@suse.com
State Superseded
Headers show
Series
  • x86: operand size handling improvements
Related show

Commit Message

Jan Beulich Aug. 6, 2019, 2:29 p.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-08-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-08-XX  Jan Beulich  <jbeulich@suse.com>

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

Comments

H.J. Lu Aug. 6, 2019, 9:11 p.m. | #1
On Tue, Aug 6, 2019 at 7:29 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).

>

> gas/

> 2019-08-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-08-XX  Jan Beulich  <jbeulich@suse.com>

>

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

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

>


We should keep the suffix even if AVX512VL isn't enabled so that
we don't need to check if AVX512VL isn't enabled to interpret the
instruction.

-- 
H.J.
Jan Beulich Aug. 7, 2019, 8:29 a.m. | #2
On 06.08.2019 23:11,  H.J. Lu  wrote:
> On Tue, Aug 6, 2019 at 7:29 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).

>>

>> gas/

>> 2019-08-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-08-XX  Jan Beulich  <jbeulich@suse.com>

>>

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

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

>>

> 

> We should keep the suffix even if AVX512VL isn't enabled so that

> we don't need to check if AVX512VL isn't enabled to interpret the

> instruction.


But that's wrong (and fixing this is the whole point of this patch).
As you've said elsewhere, unambiguous (SIMD in particular) insns
should not require any use of suffixes.

Jan
H.J. Lu Aug. 7, 2019, 6 p.m. | #3
On Wed, Aug 7, 2019 at 1:29 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 06.08.2019 23:11,  H.J. Lu  wrote:

> > On Tue, Aug 6, 2019 at 7:29 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).

> >>

> >> gas/

> >> 2019-08-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-08-XX  Jan Beulich  <jbeulich@suse.com>

> >>

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

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

> >>

> >

> > We should keep the suffix even if AVX512VL isn't enabled so that

> > we don't need to check if AVX512VL isn't enabled to interpret the

> > instruction.

>

> But that's wrong (and fixing this is the whole point of this patch).

> As you've said elsewhere, unambiguous (SIMD in particular) insns

> should not require any use of suffixes.

>


When I look at such instruction, I should be able to tell what it is without
checking if AVX512VL is enabled.

-- 
H.J.
Jan Beulich Aug. 8, 2019, 7:45 a.m. | #4
On 07.08.2019 20:00,  H.J. Lu  wrote:
> On Wed, Aug 7, 2019 at 1:29 AM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 06.08.2019 23:11,  H.J. Lu  wrote:

>>> On Tue, Aug 6, 2019 at 7:29 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).

>>>>

>>>> gas/

>>>> 2019-08-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-08-XX  Jan Beulich  <jbeulich@suse.com>

>>>>

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

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

>>>>

>>>

>>> We should keep the suffix even if AVX512VL isn't enabled so that

>>> we don't need to check if AVX512VL isn't enabled to interpret the

>>> instruction.

>>

>> But that's wrong (and fixing this is the whole point of this patch).

>> As you've said elsewhere, unambiguous (SIMD in particular) insns

>> should not require any use of suffixes.

>>

> 

> When I look at such instruction, I should be able to tell what it is without

> checking if AVX512VL is enabled.


This entirely depends on the context: When all you think about is
Knights hardware (or AVX512F/AVX512DQ in more general terms), then
seeing (and in particular being _forced_ to use) the suffix is
confusing (wrong). No-one says that in this case the suffix won't
be allowed anymore. The problem here seems to be your use of "I",
when instead you should also be considering how other people may
view things.

As a general statement: The assembler should accept (without any
diagnostic) anything that's unambiguously mappable to a valid
encoding.

Jan
H.J. Lu Aug. 8, 2019, 4:22 p.m. | #5
On Thu, Aug 8, 2019 at 12:47 AM Jan Beulich <JBeulich@suse.com> wrote:
>

> On 07.08.2019 20:00,  H.J. Lu  wrote:

> > On Wed, Aug 7, 2019 at 1:29 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> On 06.08.2019 23:11,  H.J. Lu  wrote:

> >>> On Tue, Aug 6, 2019 at 7:29 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).

> >>>>

> >>>> gas/

> >>>> 2019-08-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-08-XX  Jan Beulich  <jbeulich@suse.com>

> >>>>

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

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

> >>>>

> >>>

> >>> We should keep the suffix even if AVX512VL isn't enabled so that

> >>> we don't need to check if AVX512VL isn't enabled to interpret the

> >>> instruction.

> >>

> >> But that's wrong (and fixing this is the whole point of this patch).

> >> As you've said elsewhere, unambiguous (SIMD in particular) insns

> >> should not require any use of suffixes.

> >>

> >

> > When I look at such instruction, I should be able to tell what it is without

> > checking if AVX512VL is enabled.

>

> This entirely depends on the context: When all you think about is

> Knights hardware (or AVX512F/AVX512DQ in more general terms), then

> seeing (and in particular being _forced_ to use) the suffix is

> confusing (wrong). No-one says that in this case the suffix won't

> be allowed anymore. The problem here seems to be your use of "I",

> when instead you should also be considering how other people may

> view things.

>

> As a general statement: The assembler should accept (without any

> diagnostic) anything that's unambiguously mappable to a valid

> encoding.

>


When I debug assembly codes:

vfpclasspd $0, (%eax), %k0

it is hard to tell the memory operand size.

-- 
H.J.
Jan Beulich Aug. 9, 2019, 7:55 a.m. | #6
On 08.08.2019 18:22,  H.J. Lu  wrote:
> On Thu, Aug 8, 2019 at 12:47 AM Jan Beulich <JBeulich@suse.com> wrote:

>>

>> On 07.08.2019 20:00,  H.J. Lu  wrote:

>>> On Wed, Aug 7, 2019 at 1:29 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>

>>>> On 06.08.2019 23:11,  H.J. Lu  wrote:

>>>>> On Tue, Aug 6, 2019 at 7:29 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).

>>>>>>

>>>>>> gas/

>>>>>> 2019-08-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-08-XX  Jan Beulich  <jbeulich@suse.com>

>>>>>>

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

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

>>>>>>

>>>>>

>>>>> We should keep the suffix even if AVX512VL isn't enabled so that

>>>>> we don't need to check if AVX512VL isn't enabled to interpret the

>>>>> instruction.

>>>>

>>>> But that's wrong (and fixing this is the whole point of this patch).

>>>> As you've said elsewhere, unambiguous (SIMD in particular) insns

>>>> should not require any use of suffixes.

>>>>

>>>

>>> When I look at such instruction, I should be able to tell what it is without

>>> checking if AVX512VL is enabled.

>>

>> This entirely depends on the context: When all you think about is

>> Knights hardware (or AVX512F/AVX512DQ in more general terms), then

>> seeing (and in particular being _forced_ to use) the suffix is

>> confusing (wrong). No-one says that in this case the suffix won't

>> be allowed anymore. The problem here seems to be your use of "I",

>> when instead you should also be considering how other people may

>> view things.

>>

>> As a general statement: The assembler should accept (without any

>> diagnostic) anything that's unambiguously mappable to a valid

>> encoding.

>>

> 

> When I debug assembly codes:

> 

> vfpclasspd $0, (%eax), %k0

> 

> it is hard to tell the memory operand size.


You're kidding? The presented patch makes no change whatsoever to
the disassembler (as can also be seen from the testsuite extensions
it makes). Doing so would actually be quite hard I think without it
even knowing of the distinction between Knights family and other
processors, and without having any CPU capabilities attribute
attached to insns.

Jan
H.J. Lu Aug. 9, 2019, 2:57 p.m. | #7
On Fri, Aug 9, 2019 at 12:55 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 08.08.2019 18:22,  H.J. Lu  wrote:

> > On Thu, Aug 8, 2019 at 12:47 AM Jan Beulich <JBeulich@suse.com> wrote:

> >>

> >> On 07.08.2019 20:00,  H.J. Lu  wrote:

> >>> On Wed, Aug 7, 2019 at 1:29 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>

> >>>> On 06.08.2019 23:11,  H.J. Lu  wrote:

> >>>>> On Tue, Aug 6, 2019 at 7:29 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).

> >>>>>>

> >>>>>> gas/

> >>>>>> 2019-08-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-08-XX  Jan Beulich  <jbeulich@suse.com>

> >>>>>>

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

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

> >>>>>>

> >>>>>

> >>>>> We should keep the suffix even if AVX512VL isn't enabled so that

> >>>>> we don't need to check if AVX512VL isn't enabled to interpret the

> >>>>> instruction.

> >>>>

> >>>> But that's wrong (and fixing this is the whole point of this patch).

> >>>> As you've said elsewhere, unambiguous (SIMD in particular) insns

> >>>> should not require any use of suffixes.

> >>>>

> >>>

> >>> When I look at such instruction, I should be able to tell what it is without

> >>> checking if AVX512VL is enabled.

> >>

> >> This entirely depends on the context: When all you think about is

> >> Knights hardware (or AVX512F/AVX512DQ in more general terms), then

> >> seeing (and in particular being _forced_ to use) the suffix is

> >> confusing (wrong). No-one says that in this case the suffix won't

> >> be allowed anymore. The problem here seems to be your use of "I",

> >> when instead you should also be considering how other people may

> >> view things.

> >>

> >> As a general statement: The assembler should accept (without any

> >> diagnostic) anything that's unambiguously mappable to a valid

> >> encoding.

> >>

> >

> > When I debug assembly codes:

> >

> > vfpclasspd $0, (%eax), %k0

> >

> > it is hard to tell the memory operand size.

>

> You're kidding? The presented patch makes no change whatsoever to

> the disassembler (as can also be seen from the testsuite extensions

> it makes). Doing so would actually be quite hard I think without it

> even knowing of the distinction between Knights family and other

> processors, and without having any CPU capabilities attribute

> attached to insns.

>


I can compile assembly codes with -g and use gdb to step
through the assembly code:

Breakpoint 2, __strstr_sse2_unaligned ()
    at ../sysdeps/x86_64/multiarch/strstr-sse2-unaligned.S:22
22 movzbl (%rsi), %eax
(gdb) next
23 testb %al, %al
(gdb)

When I see

22   vfpclasspd $0, (%eax), %k0

I can't tell what the memory size is.

-- 
H.J.
Jan Beulich Aug. 9, 2019, 3:58 p.m. | #8
On 09.08.2019 16:57,  H.J. Lu  wrote:
> On Fri, Aug 9, 2019 at 12:55 AM Jan Beulich <jbeulich@suse.com> wrote:

>>

>> On 08.08.2019 18:22,  H.J. Lu  wrote:

>>> On Thu, Aug 8, 2019 at 12:47 AM Jan Beulich <JBeulich@suse.com> wrote:

>>>>

>>>> On 07.08.2019 20:00,  H.J. Lu  wrote:

>>>>> On Wed, Aug 7, 2019 at 1:29 AM Jan Beulich <jbeulich@suse.com> wrote:

>>>>>>

>>>>>> On 06.08.2019 23:11,  H.J. Lu  wrote:

>>>>>>> On Tue, Aug 6, 2019 at 7:29 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).

>>>>>>>>

>>>>>>>> gas/

>>>>>>>> 2019-08-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-08-XX  Jan Beulich  <jbeulich@suse.com>

>>>>>>>>

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

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

>>>>>>>>

>>>>>>>

>>>>>>> We should keep the suffix even if AVX512VL isn't enabled so that

>>>>>>> we don't need to check if AVX512VL isn't enabled to interpret the

>>>>>>> instruction.

>>>>>>

>>>>>> But that's wrong (and fixing this is the whole point of this patch).

>>>>>> As you've said elsewhere, unambiguous (SIMD in particular) insns

>>>>>> should not require any use of suffixes.

>>>>>>

>>>>>

>>>>> When I look at such instruction, I should be able to tell what it is without

>>>>> checking if AVX512VL is enabled.

>>>>

>>>> This entirely depends on the context: When all you think about is

>>>> Knights hardware (or AVX512F/AVX512DQ in more general terms), then

>>>> seeing (and in particular being _forced_ to use) the suffix is

>>>> confusing (wrong). No-one says that in this case the suffix won't

>>>> be allowed anymore. The problem here seems to be your use of "I",

>>>> when instead you should also be considering how other people may

>>>> view things.

>>>>

>>>> As a general statement: The assembler should accept (without any

>>>> diagnostic) anything that's unambiguously mappable to a valid

>>>> encoding.

>>>>

>>>

>>> When I debug assembly codes:

>>>

>>> vfpclasspd $0, (%eax), %k0

>>>

>>> it is hard to tell the memory operand size.

>>

>> You're kidding? The presented patch makes no change whatsoever to

>> the disassembler (as can also be seen from the testsuite extensions

>> it makes). Doing so would actually be quite hard I think without it

>> even knowing of the distinction between Knights family and other

>> processors, and without having any CPU capabilities attribute

>> attached to insns.

>>

> 

> I can compile assembly codes with -g and use gdb to step

> through the assembly code:

> 

> Breakpoint 2, __strstr_sse2_unaligned ()

>      at ../sysdeps/x86_64/multiarch/strstr-sse2-unaligned.S:22

> 22 movzbl (%rsi), %eax

> (gdb) next

> 23 testb %al, %al

> (gdb)

> 

> When I see

> 

> 22   vfpclasspd $0, (%eax), %k0

> 

> I can't tell what the memory size is.


Excuse me, but when you go through source code it is assumed
that you know what your source code means and does. No-one
requires you to omit the suffix. But equally no-one should be
required to specify a suffix just to meet your taste.

Let me be frank here: If you continue to refuse to allow this
change in, I'll have to make it work correctly for Intel syntax
mode only (which requires more code for no gain), just to avoid
the need to have you ack the change. I don't think though that
this would be a good course of action.

Jan
H.J. Lu Aug. 9, 2019, 5:13 p.m. | #9
On Fri, Aug 9, 2019 at 8:58 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 09.08.2019 16:57,  H.J. Lu  wrote:

> > On Fri, Aug 9, 2019 at 12:55 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>

> >> On 08.08.2019 18:22,  H.J. Lu  wrote:

> >>> On Thu, Aug 8, 2019 at 12:47 AM Jan Beulich <JBeulich@suse.com> wrote:

> >>>>

> >>>> On 07.08.2019 20:00,  H.J. Lu  wrote:

> >>>>> On Wed, Aug 7, 2019 at 1:29 AM Jan Beulich <jbeulich@suse.com> wrote:

> >>>>>>

> >>>>>> On 06.08.2019 23:11,  H.J. Lu  wrote:

> >>>>>>> On Tue, Aug 6, 2019 at 7:29 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).

> >>>>>>>>

> >>>>>>>> gas/

> >>>>>>>> 2019-08-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-08-XX  Jan Beulich  <jbeulich@suse.com>

> >>>>>>>>

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

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

> >>>>>>>>

> >>>>>>>

> >>>>>>> We should keep the suffix even if AVX512VL isn't enabled so that

> >>>>>>> we don't need to check if AVX512VL isn't enabled to interpret the

> >>>>>>> instruction.

> >>>>>>

> >>>>>> But that's wrong (and fixing this is the whole point of this patch).

> >>>>>> As you've said elsewhere, unambiguous (SIMD in particular) insns

> >>>>>> should not require any use of suffixes.

> >>>>>>

> >>>>>

> >>>>> When I look at such instruction, I should be able to tell what it is without

> >>>>> checking if AVX512VL is enabled.

> >>>>

> >>>> This entirely depends on the context: When all you think about is

> >>>> Knights hardware (or AVX512F/AVX512DQ in more general terms), then

> >>>> seeing (and in particular being _forced_ to use) the suffix is

> >>>> confusing (wrong). No-one says that in this case the suffix won't

> >>>> be allowed anymore. The problem here seems to be your use of "I",

> >>>> when instead you should also be considering how other people may

> >>>> view things.

> >>>>

> >>>> As a general statement: The assembler should accept (without any

> >>>> diagnostic) anything that's unambiguously mappable to a valid

> >>>> encoding.

> >>>>

> >>>

> >>> When I debug assembly codes:

> >>>

> >>> vfpclasspd $0, (%eax), %k0

> >>>

> >>> it is hard to tell the memory operand size.

> >>

> >> You're kidding? The presented patch makes no change whatsoever to

> >> the disassembler (as can also be seen from the testsuite extensions

> >> it makes). Doing so would actually be quite hard I think without it

> >> even knowing of the distinction between Knights family and other

> >> processors, and without having any CPU capabilities attribute

> >> attached to insns.

> >>

> >

> > I can compile assembly codes with -g and use gdb to step

> > through the assembly code:

> >

> > Breakpoint 2, __strstr_sse2_unaligned ()

> >      at ../sysdeps/x86_64/multiarch/strstr-sse2-unaligned.S:22

> > 22 movzbl (%rsi), %eax

> > (gdb) next

> > 23 testb %al, %al

> > (gdb)

> >

> > When I see

> >

> > 22   vfpclasspd $0, (%eax), %k0

> >

> > I can't tell what the memory size is.

>

> Excuse me, but when you go through source code it is assumed

> that you know what your source code means and does. No-one


The assembly source code can come from anywhere.

> requires you to omit the suffix. But equally no-one should be

> required to specify a suffix just to meet your taste.


These instructions can take different memory sizes.  One should
be able to tell what the memory size is by looking at it. Is that too
much to ask?

> Let me be frank here: If you continue to refuse to allow this

> change in, I'll have to make it work correctly for Intel syntax

> mode only (which requires more code for no gain), just to avoid

> the need to have you ack the change. I don't think though that

> this would be a good course of action.

>

> Jan




-- 
H.J.
Jan Beulich Aug. 12, 2019, 8:25 a.m. | #10
On 09.08.2019 19:13,  H.J. Lu  wrote:
> On Fri, Aug 9, 2019 at 8:58 AM Jan Beulich <jbeulich@suse.com> wrote:

>> On 09.08.2019 16:57,  H.J. Lu  wrote:

>>> When I see

>>>

>>> 22   vfpclasspd $0, (%eax), %k0

>>>

>>> I can't tell what the memory size is.

>>

>> Excuse me, but when you go through source code it is assumed

>> that you know what your source code means and does. No-one

> 

> The assembly source code can come from anywhere.

> 

>> requires you to omit the suffix. But equally no-one should be

>> required to specify a suffix just to meet your taste.

> 

> These instructions can take different memory sizes.  One should

> be able to tell what the memory size is by looking at it. Is that too

> much to ask?


This is not too much to ask, but is a decision of the programmers
writing assembly code, not something to enforce by gas. Once
again - given the context things may be entirely unambiguous. I
can only re-emphasize that as a maintainer you should weigh your
personal preferences against what others may think, want, or need.

>> Let me be frank here: If you continue to refuse to allow this

>> change in, I'll have to make it work correctly for Intel syntax

>> mode only (which requires more code for no gain), just to avoid

>> the need to have you ack the change. I don't think though that

>> this would be a good course of action.


I find it quite interesting that you didn't even care to comment
on this part.

Jan
H.J. Lu Aug. 13, 2019, 10:57 p.m. | #11
On Mon, Aug 12, 2019 at 1:25 AM Jan Beulich <jbeulich@suse.com> wrote:
>

> On 09.08.2019 19:13,  H.J. Lu  wrote:

> > On Fri, Aug 9, 2019 at 8:58 AM Jan Beulich <jbeulich@suse.com> wrote:

> >> On 09.08.2019 16:57,  H.J. Lu  wrote:

> >>> When I see

> >>>

> >>> 22   vfpclasspd $0, (%eax), %k0

> >>>

> >>> I can't tell what the memory size is.

> >>

> >> Excuse me, but when you go through source code it is assumed

> >> that you know what your source code means and does. No-one

> >

> > The assembly source code can come from anywhere.

> >

> >> requires you to omit the suffix. But equally no-one should be

> >> required to specify a suffix just to meet your taste.

> >

> > These instructions can take different memory sizes.  One should

> > be able to tell what the memory size is by looking at it. Is that too

> > much to ask?

>

> This is not too much to ask, but is a decision of the programmers

> writing assembly code, not something to enforce by gas. Once

> again - given the context things may be entirely unambiguous. I

> can only re-emphasize that as a maintainer you should weigh your

> personal preferences against what others may think, want, or need.


I think a suffix should be required if the memory operand size
isn't fixed by default.  One shouldn't need to know how assembly
codes is assembled to tell the memory operand size.

> >> Let me be frank here: If you continue to refuse to allow this

> >> change in, I'll have to make it work correctly for Intel syntax

> >> mode only (which requires more code for no gain), just to avoid

> >> the need to have you ack the change. I don't think though that

> >> this would be a good course of action.

>

> I find it quite interesting that you didn't even care to comment

> on this part.


That is entirely up to you.


-- 
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
@@ -6370,7 +6371,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)
@@ -6384,7 +6386,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)
@@ -6409,6 +6460,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
@@ -132,6 +132,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
@@ -100,6 +100,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
@@ -126,6 +126,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
@@ -141,6 +141,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
@@ -109,6 +109,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
@@ -134,6 +134,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
@@ -144,6 +144,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
@@ -121,6 +121,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
@@ -137,6 +137,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
@@ -4457,12 +4457,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 }