diff mbox series

[2/2] x86: fold F16C templates with their AVX512VL counterparts

Message ID 1d918dc0-4b90-4093-b261-b91bdf372d39@suse.com
State New
Headers
Series x86: AVX512VL adjustments |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_binutils_build--master-arm success Build passed
linaro-tcwg-bot/tcwg_binutils_build--master-aarch64 success Build passed
linaro-tcwg-bot/tcwg_binutils_check--master-arm success Test passed
linaro-tcwg-bot/tcwg_binutils_check--master-aarch64 success Test passed

Commit Message

Jan Beulich July 17, 2026, 1:50 p.m. UTC 
  It's not quite clear why this wasn't done so far. These, conceptually,
aren't any different from the FMA ones.

Doing so actually made me notice a flaw in FMA template handling, which is
being fixed alongside making the necessary changes to accommodate F16C:
Both features aren't prereqs of AVX512F. When they're disabled, enabling
AVX512VL would still not allow the 128- and 256-bit forms to assemble.
---
This actually points out another issue with FMA and F16C: Code created
prior to the introduction of AVX512 might have used ".arch .no{fma,f16c}"
to have uses of the respective insns properly rejected. That protection
suddenly ceased to work properly when AVX512 support was added to the
assembler: Those insns would now assemble to their AVX512VL EVEX forms.
The least bad option to deal with this looks to be to reject the AVX512VL
forms also when FMA/F16C are explicitly disabled while AVX512VL isn't
explicitly enabled. Are there any better suggestions?

Comments

Jiang, Haochen July 21, 2026, 3:16 a.m. UTC | #1 
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, July 17, 2026 9:50 PM
> 
> This actually points out another issue with FMA and F16C: Code created
> prior to the introduction of AVX512 might have used ".arch .no{fma,f16c}"
> to have uses of the respective insns properly rejected. That protection
> suddenly ceased to work properly when AVX512 support was added to the
> assembler: Those insns would now assemble to their AVX512VL EVEX forms.
> The least bad option to deal with this looks to be to reject the AVX512VL
> forms also when FMA/F16C are explicitly disabled while AVX512VL isn't
> explicitly enabled. Are there any better suggestions?

When enabling AVX512VL, those EVEX forms should be enabled since it
is an "or" claimed in SDM. It is a bug but just not reported. The behavior
is the same in GCC, where -mno-fma will not control EVEX version. The
actual flag to totally disable FMA is -ffp-contract=off.

So, I believe we should just enable those insts under this scenario. The
thing we might need to do is to add a mandatory EVEX prefix here, but
maybe tricky.

Ref from GCC repo in gcc/config/i386/sse.md, which actually applied
to all FMA, but it is mentioned in scalar part:

;; The standard names for scalar FMA are only available with SSE math enabled.
;; CPUID bit AVX512F enables evex encoded scalar and 512-bit fma.  It doesn't
;; care about FMA bit, so we enable fma for TARGET_AVX512F even when TARGET_FMA
;; and TARGET_FMA4 are both false.
;; TODO: In theory AVX512F does not automatically imply FMA, and without FMA
;; one must force the EVEX encoding of the fma insns.  Ideally we'd improve
;; GAS to allow proper prefix selection.  However, for the moment all hardware
;; that supports AVX512F also supports FMA so we can ignore this for now.

Thx,
Haochen
Jan Beulich July 21, 2026, 6:06 a.m. UTC | #2 
On 21.07.2026 05:16, Jiang, Haochen wrote:
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, July 17, 2026 9:50 PM
>>
>> This actually points out another issue with FMA and F16C: Code created
>> prior to the introduction of AVX512 might have used ".arch .no{fma,f16c}"
>> to have uses of the respective insns properly rejected. That protection
>> suddenly ceased to work properly when AVX512 support was added to the
>> assembler: Those insns would now assemble to their AVX512VL EVEX forms.
>> The least bad option to deal with this looks to be to reject the AVX512VL
>> forms also when FMA/F16C are explicitly disabled while AVX512VL isn't
>> explicitly enabled. Are there any better suggestions?
> 
> When enabling AVX512VL, those EVEX forms should be enabled since it
> is an "or" claimed in SDM. It is a bug but just not reported.

Here pretty prominently, but also elsewhere below I can't resolve ambiguities
in your reply. On one hand I'm getting the impression that you want us to
follow what the SDM mandates, while otoh ...

> The behavior
> is the same in GCC, where -mno-fma will not control EVEX version. The
> actual flag to totally disable FMA is -ffp-contract=off.
> 
> So, I believe we should just enable those insts under this scenario. The
> thing we might need to do is to add a mandatory EVEX prefix here, but
> maybe tricky.
> 
> Ref from GCC repo in gcc/config/i386/sse.md, which actually applied
> to all FMA, but it is mentioned in scalar part:
> 
> ;; The standard names for scalar FMA are only available with SSE math enabled.
> ;; CPUID bit AVX512F enables evex encoded scalar and 512-bit fma.  It doesn't
> ;; care about FMA bit, so we enable fma for TARGET_AVX512F even when TARGET_FMA
> ;; and TARGET_FMA4 are both false.
> ;; TODO: In theory AVX512F does not automatically imply FMA, and without FMA
> ;; one must force the EVEX encoding of the fma insns.  Ideally we'd improve
> ;; GAS to allow proper prefix selection.  However, for the moment all hardware
> ;; that supports AVX512F also supports FMA so we can ignore this for now.

... you quote this. If we followed this (and then also for F16C, which in gcc
doesn't have a similar comment but looks to be treated similarly).

So - are you suggesting to keep dependencies as we have them, or are you
suggesting to introduce "artificial" dependencies of AVX512F (or AVX512VL) on
FMA and F16C (thus allowing simplification here and perhaps elsewhere)? Or
yet something else?

Jan
Jiang, Haochen July 21, 2026, 6:18 a.m. UTC | #3 
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Tuesday, July 21, 2026 2:07 PM
> 
> On 21.07.2026 05:16, Jiang, Haochen wrote:
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Friday, July 17, 2026 9:50 PM
> >>
> >> This actually points out another issue with FMA and F16C: Code created
> >> prior to the introduction of AVX512 might have used ".arch .no{fma,f16c}"
> >> to have uses of the respective insns properly rejected. That protection
> >> suddenly ceased to work properly when AVX512 support was added to the
> >> assembler: Those insns would now assemble to their AVX512VL EVEX forms.
> >> The least bad option to deal with this looks to be to reject the AVX512VL
> >> forms also when FMA/F16C are explicitly disabled while AVX512VL isn't
> >> explicitly enabled. Are there any better suggestions?
> >
> > When enabling AVX512VL, those EVEX forms should be enabled since it
> > is an "or" claimed in SDM. It is a bug but just not reported.
> 
> Here pretty prominently, but also elsewhere below I can't resolve ambiguities
> in your reply. On one hand I'm getting the impression that you want us to
> follow what the SDM mandates, while otoh ...

To be clear, I mean it is not SDM bug. .nofma disabling EVEX FMA is buggy
to me. 

> 
> > The behavior
> > is the same in GCC, where -mno-fma will not control EVEX version. The
> > actual flag to totally disable FMA is -ffp-contract=off.
> >
> > So, I believe we should just enable those insts under this scenario. The
> > thing we might need to do is to add a mandatory EVEX prefix here, but
> > maybe tricky.
> >
> > Ref from GCC repo in gcc/config/i386/sse.md, which actually applied
> > to all FMA, but it is mentioned in scalar part:
> >
> > ;; The standard names for scalar FMA are only available with SSE math enabled.
> > ;; CPUID bit AVX512F enables evex encoded scalar and 512-bit fma.  It doesn't
> > ;; care about FMA bit, so we enable fma for TARGET_AVX512F even when TARGET_FMA
> > ;; and TARGET_FMA4 are both false.
> > ;; TODO: In theory AVX512F does not automatically imply FMA, and without FMA
> > ;; one must force the EVEX encoding of the fma insns.  Ideally we'd improve
> > ;; GAS to allow proper prefix selection.  However, for the moment all hardware
> > ;; that supports AVX512F also supports FMA so we can ignore this for now.
> 
> ... you quote this. If we followed this (and then also for F16C, which in gcc
> doesn't have a similar comment but looks to be treated similarly).
> 
> So - are you suggesting to keep dependencies as we have them, or are you
> suggesting to introduce "artificial" dependencies of AVX512F (or AVX512VL)
> on FMA and F16C (thus allowing simplification here and perhaps elsewhere)? Or
> yet something else?
> 

I suppose .nofma should only disable VEX version FMA, leaving EVEX version there
(better with {evex} prefix). Similar for F16C.

Thx,
Haochen
Jan Beulich July 21, 2026, 6:37 a.m. UTC | #4 
On 21.07.2026 08:18, Jiang, Haochen wrote:
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Tuesday, July 21, 2026 2:07 PM
>>
>> On 21.07.2026 05:16, Jiang, Haochen wrote:
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Friday, July 17, 2026 9:50 PM
>>>>
>>>> This actually points out another issue with FMA and F16C: Code created
>>>> prior to the introduction of AVX512 might have used ".arch .no{fma,f16c}"
>>>> to have uses of the respective insns properly rejected. That protection
>>>> suddenly ceased to work properly when AVX512 support was added to the
>>>> assembler: Those insns would now assemble to their AVX512VL EVEX forms.
>>>> The least bad option to deal with this looks to be to reject the AVX512VL
>>>> forms also when FMA/F16C are explicitly disabled while AVX512VL isn't
>>>> explicitly enabled. Are there any better suggestions?
>>>
>>> When enabling AVX512VL, those EVEX forms should be enabled since it
>>> is an "or" claimed in SDM. It is a bug but just not reported.
>>
>> Here pretty prominently, but also elsewhere below I can't resolve ambiguities
>> in your reply. On one hand I'm getting the impression that you want us to
>> follow what the SDM mandates, while otoh ...
> 
> To be clear, I mean it is not SDM bug. .nofma disabling EVEX FMA is buggy
> to me. 
> 
>>
>>> The behavior
>>> is the same in GCC, where -mno-fma will not control EVEX version. The
>>> actual flag to totally disable FMA is -ffp-contract=off.
>>>
>>> So, I believe we should just enable those insts under this scenario. The
>>> thing we might need to do is to add a mandatory EVEX prefix here, but
>>> maybe tricky.
>>>
>>> Ref from GCC repo in gcc/config/i386/sse.md, which actually applied
>>> to all FMA, but it is mentioned in scalar part:
>>>
>>> ;; The standard names for scalar FMA are only available with SSE math enabled.
>>> ;; CPUID bit AVX512F enables evex encoded scalar and 512-bit fma.  It doesn't
>>> ;; care about FMA bit, so we enable fma for TARGET_AVX512F even when TARGET_FMA
>>> ;; and TARGET_FMA4 are both false.
>>> ;; TODO: In theory AVX512F does not automatically imply FMA, and without FMA
>>> ;; one must force the EVEX encoding of the fma insns.  Ideally we'd improve
>>> ;; GAS to allow proper prefix selection.  However, for the moment all hardware
>>> ;; that supports AVX512F also supports FMA so we can ignore this for now.
>>
>> ... you quote this. If we followed this (and then also for F16C, which in gcc
>> doesn't have a similar comment but looks to be treated similarly).
>>
>> So - are you suggesting to keep dependencies as we have them, or are you
>> suggesting to introduce "artificial" dependencies of AVX512F (or AVX512VL)
>> on FMA and F16C (thus allowing simplification here and perhaps elsewhere)? Or
>> yet something else?
> 
> I suppose .nofma should only disable VEX version FMA, leaving EVEX version there
> (better with {evex} prefix). Similar for F16C.

Ah, you want to _demand_ presence of the prefix, for disambiguation. Let me
think about this; at the first glance it feels like this may be a little
intrusive, but maybe I'm wrong.

Jan
diff mbox series

Patch

--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -2314,14 +2314,18 @@  cpu_flags_match (const insn_template *t)
     {
       /* Dual AVX/AVX512 templates need to retain AVX512* only if we already
 	 know that EVEX encoding will be needed.  */
-      if ((any.bitfield.cpuavx || any.bitfield.cpuavx2 || any.bitfield.cpufma)
+      if ((any.bitfield.cpuavx || any.bitfield.cpuavx2
+	   || any.bitfield.cpufma || any.bitfield.cpuf16c)
 	  && (any.bitfield.cpuavx512f || any.bitfield.cpuavx512vl))
 	{
-	  if (need_evex_encoding (t))
+	  if (need_evex_encoding (t)
+	      || (any.bitfield.cpufma && !cpu_arch_flags.bitfield.cpufma)
+	      || (any.bitfield.cpuf16c && !cpu_arch_flags.bitfield.cpuf16c))
 	    {
 	      any.bitfield.cpuavx = 0;
 	      any.bitfield.cpuavx2 = 0;
 	      any.bitfield.cpufma = 0;
+	      any.bitfield.cpuf16c = 0;
 	    }
 	  /* need_evex_encoding(t) isn't reliable before operands were
 	     parsed.  */
@@ -4232,10 +4236,12 @@  install_template (const insn_template *t
   if (t->opcode_modifier.vex && t->opcode_modifier.evex)
     {
       if ((maybe_cpu (t, CpuAVX) || maybe_cpu (t, CpuAVX2)
-	   || maybe_cpu (t, CpuFMA))
+	   || maybe_cpu (t, CpuFMA) || maybe_cpu (t, CpuF16C))
 	  && (maybe_cpu (t, CpuAVX512F) || maybe_cpu (t, CpuAVX512VL)))
 	{
-	  if (need_evex_encoding (t))
+	  if (need_evex_encoding (t)
+	      || (maybe_cpu (t, CpuFMA) && !cpu_arch_flags.bitfield.cpufma)
+	      || (maybe_cpu (t, CpuF16C) && !cpu_arch_flags.bitfield.cpuf16c))
 	    {
 	      i.tm.opcode_modifier.vex = 0;
 	      i.tm.cpu.bitfield.cpuavx512f = i.tm.cpu_any.bitfield.cpuavx512f;
@@ -8799,7 +8805,10 @@  check_VecOperands (const insn_template *
   if (!cpu_flags_all_zero (&cpu)
       && !cpu.bitfield.cpuavx512vl
       && !cpu_arch_flags.bitfield.cpuavx512vl
-      && (!t->opcode_modifier.vex || need_evex_encoding (t)))
+      && (!t->opcode_modifier.vex || need_evex_encoding (t)
+	  /* Note: No need to check F16C here.  Those insns have distinct
+	     templates for distinct VEX.L / EVEX.L'L.  */
+	  || (maybe_cpu (t, CpuFMA) && !cpu_arch_flags.bitfield.cpufma)))
     {
       for (op = 0; op < t->operands; ++op)
 	{
--- a/gas/testsuite/gas/i386/avx512vl-plain.l
+++ b/gas/testsuite/gas/i386/avx512vl-plain.l
@@ -1,8 +1,8 @@ 
 .*: Assembler messages:
 .*:5: Error: .*
-.*:6: Error: .*
-.*:7: Error: .*
-.*:20: Error: .*
+.*:8: Error: .*
+.*:9: Error: .*
+.*:22: Error: .*
 GAS LISTING .*
 
 
@@ -11,23 +11,27 @@  GAS LISTING .*
 [ 	]*3[ 	]+\.arch \.avx512vl
 [ 	]*4[ 	]+_start:
 [ 	]*5[ 	]+\{evex\} vaesenc[ 	]+%ymm1, %ymm2, %ymm3
-[ 	]*6[ 	]+vgf2p8mulb[ 	]+%ymm1, %ymm2, %ymm3\{%k4\}
-[ 	]*7[ 	]+\{evex\} vpclmulqdq[ 	]+\$0, %ymm1, %ymm2, %ymm3
-[ 	]*8[ 	]*
-[ 	]*9[ 	]+\.arch \.vaes
-[ 	]*10[ 	]+\?\?\?\? 62F26D28[ 	]+\{evex\} vaesenc[ 	]+%ymm1, %ymm2, %ymm3
-[ 	]*10[ 	]+DCD9
-[ 	]*11[ 	]*
-[ 	]*12[ 	]+\.arch \.gfni
-[ 	]*13[ 	]+\?\?\?\? 62F26D2C[ 	]+vgf2p8mulb[ 	]+%ymm1, %ymm2, %ymm3\{%k4\}
-[ 	]*13[ 	]+CFD9
-[ 	]*14[ 	]*
-[ 	]*15[ 	]+\.arch \.vpclmulqdq
-[ 	]*16[ 	]+\?\?\?\? 62F36D28[ 	]+\{evex\} vpclmulqdq[ 	]+\$0, %ymm1, %ymm2, %ymm3
-[ 	]*16[ 	]+44D900
-[ 	]*17[ 	]*
-[ 	]*18[ 	]+\.arch generic32
-[ 	]*19[ 	]+\.arch \.avx512f
-[ 	]*20[ 	]+\{evex\}[ 	]+vpermd[ 	]+%ymm1, %ymm2, %ymm3
-[ 	]*21[ 	]+\?\?\?\? C4E26D36[ 	]+vpermd[ 	]+%ymm1, %ymm2, %ymm3
+[ 	]*6[ 	]+\?\?\?\? 62F27D08[ 	]+vcvtph2ps[ 	]+%xmm1, %xmm2
+[ 	]*6[ 	]+13D1
+[ 	]*7[ 	]+\?\?\?\? 62F26D08[ 	]+vfmadd132ps[ 	]+%xmm1, %xmm2, %xmm3
+[ 	]*7[ 	]+98D9
+[ 	]*8[ 	]+vgf2p8mulb[ 	]+%ymm1, %ymm2, %ymm3\{%k4\}
+[ 	]*9[ 	]+\{evex\} vpclmulqdq[ 	]+\$0, %ymm1, %ymm2, %ymm3
+[ 	]*10[ 	]*
+[ 	]*11[ 	]+\.arch \.vaes
+[ 	]*12[ 	]+\?\?\?\? 62F26D28[ 	]+\{evex\} vaesenc[ 	]+%ymm1, %ymm2, %ymm3
+[ 	]*12[ 	]+DCD9
+[ 	]*13[ 	]*
+[ 	]*14[ 	]+\.arch \.gfni
+[ 	]*15[ 	]+\?\?\?\? 62F26D2C[ 	]+vgf2p8mulb[ 	]+%ymm1, %ymm2, %ymm3\{%k4\}
+[ 	]*15[ 	]+CFD9
+[ 	]*16[ 	]*
+[ 	]*17[ 	]+\.arch \.vpclmulqdq
+[ 	]*18[ 	]+\?\?\?\? 62F36D28[ 	]+\{evex\} vpclmulqdq[ 	]+\$0, %ymm1, %ymm2, %ymm3
+[ 	]*18[ 	]+44D900
+[ 	]*19[ 	]*
+[ 	]*20[ 	]+\.arch generic32
+[ 	]*21[ 	]+\.arch \.avx512f
+[ 	]*22[ 	]+\{evex\}[ 	]+vpermd[ 	]+%ymm1, %ymm2, %ymm3
+[ 	]*23[ 	]+\?\?\?\? C4E26D36[ 	]+vpermd[ 	]+%ymm1, %ymm2, %ymm3
 #pass
--- a/gas/testsuite/gas/i386/avx512vl-plain.s
+++ b/gas/testsuite/gas/i386/avx512vl-plain.s
@@ -3,6 +3,8 @@ 
 	.arch .avx512vl
 _start:
 	{evex} vaesenc		%ymm1, %ymm2, %ymm3
+	       vcvtph2ps	%xmm1, %xmm2
+	       vfmadd132ps	%xmm1, %xmm2, %xmm3
 	       vgf2p8mulb	%ymm1, %ymm2, %ymm3{%k4}
 	{evex} vpclmulqdq	$0, %ymm1, %ymm2, %ymm3
 
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -1922,17 +1922,20 @@  vgf2p8affineinvqb, 0x66cf, AVX&GFNI, Mod
 vgf2p8affineqb, 0x66ce, AVX&GFNI, Modrm|Vex|Space0F3A|Src1VVVV|VexW1|CheckOperandSize|NoSuf, { Imm8, Unspecified|BaseIndex|RegXMM|RegYMM, RegXMM|RegYMM, RegXMM|RegYMM }
 vgf2p8mulb, 0x66cf, GFNI&(AVX|AVX512F), Modrm|Vex|EVexDYN|Masking|Space0F38|Src1VVVV|VexW0|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegXMM|RegYMM|RegZMM|Unspecified|BaseIndex, RegXMM|RegYMM|RegZMM, RegXMM|RegYMM|RegZMM }
 
-// FSGSBASE, RDRND and F16C
+// FSGSBASE and RDRND
 
 rdfsbase, 0xf30fae/0, FSGSBase, Modrm|IgnoreSize|NoSuf, { Reg32|Reg64 }
 rdgsbase, 0xf30fae/1, FSGSBase, Modrm|IgnoreSize|NoSuf, { Reg32|Reg64 }
 rdrand, 0xfc7/6, RdRnd, Modrm|NoSuf, { Reg16|Reg32|Reg64 }
 wrfsbase, 0xf30fae/2, FSGSBase, Modrm|IgnoreSize|NoSuf, { Reg32|Reg64 }
 wrgsbase, 0xf30fae/3, FSGSBase, Modrm|IgnoreSize|NoSuf, { Reg32|Reg64 }
-vcvtph2ps, 0x6613, F16C, Modrm|Vex|Space0F38|VexW0|NoSuf, { Qword|Unspecified|BaseIndex|RegXMM, RegXMM }
-vcvtph2ps, 0x6613, F16C, Modrm|Vex=2|Space0F38|VexW=1|NoSuf, { Unspecified|BaseIndex|RegXMM, RegYMM }
-vcvtps2ph, 0x661d, F16C, Modrm|Vex|Space0F3A|VexW0|NoSuf, { Imm8, RegXMM, Qword|Unspecified|BaseIndex|RegXMM }
-vcvtps2ph, 0x661d, F16C, Modrm|Vex=2|Space0F3A|VexW=1|NoSuf, { Imm8, RegYMM, Unspecified|BaseIndex|RegXMM }
+
+// F16C instructions
+
+vcvtph2ps, 0x6613, F16C|AVX512VL, Modrm|Vex128|EVex128|Masking|Space0F38|VexW0|Disp8MemShift=3|NoSuf, { Qword|Unspecified|BaseIndex|RegXMM, RegXMM }
+vcvtph2ps, 0x6613, F16C|AVX512VL, Modrm|Vex256|EVex256|Masking|Space0F38|VexW0|Disp8MemShift=4|NoSuf, { Unspecified|BaseIndex|RegXMM, RegYMM }
+vcvtps2ph, 0x661d, F16C|AVX512VL, Modrm|Vex128|EVex128|Masking|Space0F3A|VexW0|Disp8MemShift=3|NoSuf, { Imm8, RegXMM, Qword|Unspecified|BaseIndex|RegXMM }
+vcvtps2ph, 0x661d, F16C|AVX512VL, Modrm|Vex256|EVex256|Masking|Space0F3A|VexW0|Disp8MemShift=4|NoSuf, { Imm8, RegYMM, Unspecified|BaseIndex|RegXMM }
 
 // FMA instructions
 
@@ -2655,15 +2658,9 @@  vcvtdq2pd, 0xF3E6, AVX512VL, Modrm|EVex2
 vcvtudq2pd, 0xF37A, AVX512VL, Modrm|EVex128|Masking|Space0F|VexW0|Broadcast|Disp8MemShift=3|NoSuf, { RegXMM|Dword|Qword|Unspecified|BaseIndex, RegXMM }
 vcvtudq2pd, 0xF37A, AVX512VL, Modrm|EVex256|Masking|Space0F|VexW0|Broadcast|Disp8MemShift=4|NoSuf, { RegXMM|Dword|Unspecified|BaseIndex, RegYMM }
 
-vcvtph2ps, 0x6613, AVX512VL, Modrm|EVex=2|Masking|Space0F38|VexW0|Disp8MemShift=3|NoSuf, { RegXMM|Qword|Unspecified|BaseIndex, RegXMM }
-vcvtph2ps, 0x6613, AVX512VL, Modrm|EVex=3|Masking|Space0F38|VexW=1|Disp8MemShift=4|NoSuf, { RegXMM|Unspecified|BaseIndex, RegYMM }
-
 vcvtps2pd, 0x5A, AVX512VL, Modrm|EVex128|Masking|Space0F|VexW0|Broadcast|Disp8MemShift=3|NoSuf, { RegXMM|Dword|Qword|Unspecified|BaseIndex, RegXMM }
 vcvtps2pd, 0x5A, AVX512VL, Modrm|EVex256|Masking|Space0F|VexW0|Broadcast|Disp8MemShift=4|NoSuf, { RegXMM|Dword|Unspecified|BaseIndex, RegYMM }
 
-vcvtps2ph, 0x661D, AVX512VL, Modrm|EVex128|Masking|Space0F3A|VexW0|Disp8MemShift=3|NoSuf, { Imm8, RegXMM, RegXMM|Qword|Unspecified|BaseIndex }
-vcvtps2ph, 0x661D, AVX512VL, Modrm|EVex256|Masking|Space0F3A|VexW0|Disp8MemShift=4|NoSuf, { Imm8, RegYMM, RegXMM|Unspecified|BaseIndex }
-
 vmovddup, 0xF212, AVX512VL, Modrm|EVex=2|Masking|Space0F|VexW1|Disp8MemShift=3|NoSuf, { RegXMM|Qword|Unspecified|BaseIndex, RegXMM }
 
 vp<movn>db, 0xf3<movn:opc>1, AVX512VL, Modrm|EVex128|Masking|Space0F38|VexW0|Disp8MemShift=2|NoSuf, { RegXMM, RegXMM|Dword|Unspecified|BaseIndex }