diff mbox series

x86: separate AVX10.1-aux from AVX10.2

Message ID 3844e419-ea84-4ca6-8a9b-1fa9d83cac97@suse.com
State New
Headers
Series x86: separate AVX10.1-aux from AVX10.2 |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_binutils_build--master-arm fail Patch failed to apply
linaro-tcwg-bot/tcwg_binutils_build--master-aarch64 fail Patch failed to apply

Commit Message

Jan Beulich July 10, 2026, 12:22 p.m. UTC 
  As the reduced set can be all that's available, we want to permit people
to also restrict the recognized ISA accordingly.
---
Making a dependency chain 10.1 -> 10.1aux -> 10.2 (and soon ->10.2aux) is
easier than having respective templates specify AVX10_1_AUX|AVX10_2. Are
there clear reasons speaking against this approach?

I'm unconvinced of spelling out the (largely deprecated) avx10.1aux/512
etc forms in the doc. Perhaps that shouldn't even have been done for
AVX10.2.

This is assumed to go on top of "x86: accept LOCK on control register
accesses only with ModR/M.reg == 0". Functionally there of course is no
conflict, but at least the doc changes collide.

Comments

Jiang, Haochen July 13, 2026, 2:20 a.m. UTC | #1 
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, July 10, 2026 8:23 PM
> 
> Making a dependency chain 10.1 -> 10.1aux -> 10.2 (and soon ->10.2aux) is

Just for clarification, but won't affect this patch, Intel will follow this, but I can't
speak for AMD if this is true.

> easier than having respective templates specify AVX10_1_AUX|AVX10_2. Are
> there clear reasons speaking against this approach?
> 

I believe this is the right approach for Intel and AMD current implementation.
If there is any other vendors against that, they could change afterwards.

> I'm unconvinced of spelling out the (largely deprecated) avx10.1aux/512
> etc forms in the doc. Perhaps that shouldn't even have been done for
> AVX10.2.

I agree with the current documentation based on current 512-bit vector
size support on all HW.

> 
> --- a/gas/config/tc-i386.c
> +++ b/gas/config/tc-i386.c
> @@ -1247,13 +1247,14 @@ static const arch_entry cpu_arch[] =
>    VECARCH (sm4, SM4, ANY_SM4, reset),
>    SUBARCH (pbndkb, PBNDKB, PBNDKB, false),
>    VECARCH (avx10.1, AVX10_1, ANY_AVX512F, set),
> +  VECARCH (avx10.1aux, AVX10_1_AUX, ANY_AVX10_1_AUX, set),

Maybe avx10_v1_aux instead of avx10.1aux to align with documentation?

> --- a/opcodes/i386-opc.h
> +++ b/opcodes/i386-opc.h
> @@ -209,6 +209,8 @@ enum i386_cpu
>    CpuAVX512_VP2INTERSECT,
>    /* AMD AVX-512 BMM Instructions support required.  */
>    CpuAVX512_BMM,
> +  /* Intel AVX10.1-aux Instructions support required.  */

For those joint ISAs, we might need to use x86 in the future
instead of Intel/AMD.

> +  CpuAVX10_1_AUX,

Thx,
Haochen
Jan Beulich July 13, 2026, 6:30 a.m. UTC | #2 
On 13.07.2026 04:20, Jiang, Haochen wrote:
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, July 10, 2026 8:23 PM
>>
>> --- a/gas/config/tc-i386.c
>> +++ b/gas/config/tc-i386.c
>> @@ -1247,13 +1247,14 @@ static const arch_entry cpu_arch[] =
>>    VECARCH (sm4, SM4, ANY_SM4, reset),
>>    SUBARCH (pbndkb, PBNDKB, PBNDKB, false),
>>    VECARCH (avx10.1, AVX10_1, ANY_AVX512F, set),
>> +  VECARCH (avx10.1aux, AVX10_1_AUX, ANY_AVX10_1_AUX, set),
> 
> Maybe avx10_v1_aux instead of avx10.1aux to align with documentation?

I was wondering, but imo the existing "avx10.1" makes it pretty clear cut.
I would have wanted to make it "avx10.1-aux", but dashes aren't okay to use
here, and "avx10.1_aux" feels somewhat odd.

>> --- a/opcodes/i386-opc.h
>> +++ b/opcodes/i386-opc.h
>> @@ -209,6 +209,8 @@ enum i386_cpu
>>    CpuAVX512_VP2INTERSECT,
>>    /* AMD AVX-512 BMM Instructions support required.  */
>>    CpuAVX512_BMM,
>> +  /* Intel AVX10.1-aux Instructions support required.  */
> 
> For those joint ISAs, we might need to use x86 in the future
> instead of Intel/AMD.

And again - indeed I was wondering. Yet right now AVX10 (up to 10.2) is
still very much an Intel-only spec. 10.2-aux is the odd one for the time
being. That said, I'm certainly okay to omit "Intel" here right away.

Jan
Jiang, Haochen July 13, 2026, 8:50 a.m. UTC | #3 
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Monday, July 13, 2026 2:30 PM
> 
> On 13.07.2026 04:20, Jiang, Haochen wrote:
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Friday, July 10, 2026 8:23 PM
> >>
> >> --- a/gas/config/tc-i386.c
> >> +++ b/gas/config/tc-i386.c
> >> @@ -1247,13 +1247,14 @@ static const arch_entry cpu_arch[] =
> >>    VECARCH (sm4, SM4, ANY_SM4, reset),
> >>    SUBARCH (pbndkb, PBNDKB, PBNDKB, false),
> >>    VECARCH (avx10.1, AVX10_1, ANY_AVX512F, set),
> >> +  VECARCH (avx10.1aux, AVX10_1_AUX, ANY_AVX10_1_AUX, set),
> >
> > Maybe avx10_v1_aux instead of avx10.1aux to align with documentation?
> 
> I was wondering, but imo the existing "avx10.1" makes it pretty clear cut.
> I would have wanted to make it "avx10.1-aux", but dashes aren't okay to use
> here, and "avx10.1_aux" feels somewhat odd.

If we do not want to use v1, then the current name is definitely a win.

This is an AMD proposed feature bit actually, while Intel will emulate that bit
to avoid break on HW. So, let's wait AMD folks to share their opinion on option
names. We also need to make sure that it is the same naming convention as
AVX10_V2_AUX.

Thx,
Haochen
Jiang, Haochen July 17, 2026, 6:31 a.m. UTC | #4 
> From: Jiang, Haochen
> Sent: Monday, July 13, 2026 4:50 PM
> 
> > From: Jan Beulich <jbeulich@suse.com>
> > Sent: Monday, July 13, 2026 2:30 PM
> >
> > On 13.07.2026 04:20, Jiang, Haochen wrote:
> > >> From: Jan Beulich <jbeulich@suse.com>
> > >> Sent: Friday, July 10, 2026 8:23 PM
> > >>
> > >> --- a/gas/config/tc-i386.c
> > >> +++ b/gas/config/tc-i386.c
> > >> @@ -1247,13 +1247,14 @@ static const arch_entry cpu_arch[] =
> > >>    VECARCH (sm4, SM4, ANY_SM4, reset),
> > >>    SUBARCH (pbndkb, PBNDKB, PBNDKB, false),
> > >>    VECARCH (avx10.1, AVX10_1, ANY_AVX512F, set),
> > >> +  VECARCH (avx10.1aux, AVX10_1_AUX, ANY_AVX10_1_AUX, set),
> > >
> > > Maybe avx10_v1_aux instead of avx10.1aux to align with documentation?
> >
> > I was wondering, but imo the existing "avx10.1" makes it pretty clear cut.
> > I would have wanted to make it "avx10.1-aux", but dashes aren't okay to use
> > here, and "avx10.1_aux" feels somewhat odd.
> 
> If we do not want to use v1, then the current name is definitely a win.
> 
> This is an AMD proposed feature bit actually, while Intel will emulate that bit
> to avoid break on HW. So, let's wait AMD folks to share their opinion on option
> names. We also need to make sure that it is the same naming convention as
> AVX10_V2_AUX.
> 

Ping for this discussion, Ganesh, what is AMD's opinion on this? Do you want
to keep the "v" in name? Whatever it is, we need to keep the naming convention
same between AVX10_V1_AUX and AVX10_V2_AUX.

Thx,
Haochen
Jan Beulich July 24, 2026, 6:32 a.m. UTC | #5 
On 17.07.2026 08:31, Jiang, Haochen wrote:
>> From: Jiang, Haochen
>> Sent: Monday, July 13, 2026 4:50 PM
>>
>>> From: Jan Beulich <jbeulich@suse.com>
>>> Sent: Monday, July 13, 2026 2:30 PM
>>>
>>> On 13.07.2026 04:20, Jiang, Haochen wrote:
>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>> Sent: Friday, July 10, 2026 8:23 PM
>>>>>
>>>>> --- a/gas/config/tc-i386.c
>>>>> +++ b/gas/config/tc-i386.c
>>>>> @@ -1247,13 +1247,14 @@ static const arch_entry cpu_arch[] =
>>>>>    VECARCH (sm4, SM4, ANY_SM4, reset),
>>>>>    SUBARCH (pbndkb, PBNDKB, PBNDKB, false),
>>>>>    VECARCH (avx10.1, AVX10_1, ANY_AVX512F, set),
>>>>> +  VECARCH (avx10.1aux, AVX10_1_AUX, ANY_AVX10_1_AUX, set),
>>>>
>>>> Maybe avx10_v1_aux instead of avx10.1aux to align with documentation?
>>>
>>> I was wondering, but imo the existing "avx10.1" makes it pretty clear cut.
>>> I would have wanted to make it "avx10.1-aux", but dashes aren't okay to use
>>> here, and "avx10.1_aux" feels somewhat odd.
>>
>> If we do not want to use v1, then the current name is definitely a win.
>>
>> This is an AMD proposed feature bit actually, while Intel will emulate that bit
>> to avoid break on HW. So, let's wait AMD folks to share their opinion on option
>> names. We also need to make sure that it is the same naming convention as
>> AVX10_V2_AUX.
> 
> Ping for this discussion, Ganesh, what is AMD's opinion on this? Do you want
> to keep the "v" in name? Whatever it is, we need to keep the naming convention
> same between AVX10_V1_AUX and AVX10_V2_AUX.

Short of further feedback I've put this in. We still have some time to massage
things, before the 2.48 release.

Jan
Jiang, Haochen July 24, 2026, 6:37 a.m. UTC | #6 
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, July 24, 2026 2:33 PM
> 
> On 17.07.2026 08:31, Jiang, Haochen wrote:
> >> From: Jiang, Haochen
> >> Sent: Monday, July 13, 2026 4:50 PM
> >>
> >>> From: Jan Beulich <jbeulich@suse.com>
> >>> Sent: Monday, July 13, 2026 2:30 PM
> >>>
> >>> On 13.07.2026 04:20, Jiang, Haochen wrote:
> >>>>> From: Jan Beulich <jbeulich@suse.com>
> >>>>> Sent: Friday, July 10, 2026 8:23 PM
> >>>>>
> >>>>> --- a/gas/config/tc-i386.c
> >>>>> +++ b/gas/config/tc-i386.c
> >>>>> @@ -1247,13 +1247,14 @@ static const arch_entry cpu_arch[] =
> >>>>>    VECARCH (sm4, SM4, ANY_SM4, reset),
> >>>>>    SUBARCH (pbndkb, PBNDKB, PBNDKB, false),
> >>>>>    VECARCH (avx10.1, AVX10_1, ANY_AVX512F, set),
> >>>>> +  VECARCH (avx10.1aux, AVX10_1_AUX, ANY_AVX10_1_AUX, set),
> >>>>
> >>>> Maybe avx10_v1_aux instead of avx10.1aux to align with documentation?
> >>>
> >>> I was wondering, but imo the existing "avx10.1" makes it pretty clear cut.
> >>> I would have wanted to make it "avx10.1-aux", but dashes aren't okay to use
> >>> here, and "avx10.1_aux" feels somewhat odd.
> >>
> >> If we do not want to use v1, then the current name is definitely a win.
> >>
> >> This is an AMD proposed feature bit actually, while Intel will emulate that bit
> >> to avoid break on HW. So, let's wait AMD folks to share their opinion on option
> >> names. We also need to make sure that it is the same naming convention as
> >> AVX10_V2_AUX.
> >
> > Ping for this discussion, Ganesh, what is AMD's opinion on this? Do you want
> > to keep the "v" in name? Whatever it is, we need to keep the naming convention
> > same between AVX10_V1_AUX and AVX10_V2_AUX.
> 
> Short of further feedback I've put this in. We still have some time to massage
> things, before the 2.48 release.
> 

+ Venkat from AMD for feedback.

As long as we keep the same naming convention between AVX10_V1_AUX and
AVX10_V2_AUX, it is ok to me.

Thx,
Haochen
Gopalasubramanian, Ganesh July 24, 2026, 10:36 a.m. UTC | #7 
AMD General

In clang and in GCC, we are using -mavx10v2aux. I would suggest using avx10v1aux!

Regards
Ganesh
Jan Beulich July 24, 2026, 10:41 a.m. UTC | #8 
On 24.07.2026 12:36, Gopalasubramanian, Ganesh wrote:
> In clang and in GCC, we are using -mavx10v2aux. I would suggest using avx10v1aux!

Okay(ish) with me, but as you're coming pretty late, would you mind making
this a small prereq patch to your ACE and AVX10.2-aux work then?

Jan
Kumar, Venkataramanan July 24, 2026, 10:52 a.m. UTC | #9 
AMD General

Hi

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, July 24, 2026 4:12 PM
> To: Gopalasubramanian, Ganesh <Ganesh.Gopalasubramanian@amd.com>
> Cc: H.J. Lu <hjl.tools@gmail.com>; Binutils <binutils@sourceware.org>; Kumar,
> Venkataramanan <Venkataramanan.Kumar@amd.com>; Jiang, Haochen
> <haochen.jiang@intel.com>
> Subject: Re: [PATCH] x86: separate AVX10.1-aux from AVX10.2
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 24.07.2026 12:36, Gopalasubramanian, Ganesh wrote:
> > In clang and in GCC, we are using -mavx10v2aux. I would suggest using
> avx10v1aux!
>
> Okay(ish) with me, but as you're coming pretty late, would you mind making this a
> small prereq patch to your ACE and AVX10.2-aux work then?

In GCC also names will be -mavx10v1aux and -mavx10v2aux.

Regards,
Venkat.

>
> Jan
diff mbox series

Patch

--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1247,13 +1247,14 @@  static const arch_entry cpu_arch[] =
   VECARCH (sm4, SM4, ANY_SM4, reset),
   SUBARCH (pbndkb, PBNDKB, PBNDKB, false),
   VECARCH (avx10.1, AVX10_1, ANY_AVX512F, set),
+  VECARCH (avx10.1aux, AVX10_1_AUX, ANY_AVX10_1_AUX, set),
+  VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),
   SUBARCH (user_msr, USER_MSR, USER_MSR, false),
   SUBARCH (apx_f, APX_F, ANY_APX_F, false),
   SUBARCH (apx_nci, APX_NCI, ANY_APX_NCI, false),
   SUBARCH (apx_ndd, APX_NDD, ANY_APX_NDD, false),
   SUBARCH (apx_nf, APX_NF, ANY_APX_NF, false),
   SUBARCH (apx_nci_ndd_nf, APX_NCI_NDD_NF, ANY_APX_NCI_NDD_NF, false),
-  VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),
   SUBARCH (gmism2, GMISM2, GMISM2, false),
   SUBARCH (gmiccs, GMICCS, GMICCS, false),
   SUBARCH (msr_imm, MSR_IMM, MSR_IMM, false),
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -220,6 +220,7 @@  accept various extension mnemonics.  For
 @code{avx10.1/512},
 @code{avx10.1/256},
 @code{avx10.1/128},
+@code{avx10.1aux},
 @code{user_msr},
 @code{msr_imm},
 @code{apx_f},
@@ -1718,13 +1719,13 @@  supported on the CPU specified.  The cho
 @item @samp{.avx512_vpopcntdq} @tab @samp{.avx512_vbmi2} @tab @samp{.avx512_vnni}
 @item @samp{.avx512_bitalg} @tab @samp{.avx512_bf16} @tab @samp{.avx512_vp2intersect}
 @item @samp{.tdx} @tab @samp{.avx_vnni} @tab @samp{.avx512_fp16} @tab @samp{avx512_bmm}
-@item @samp{.avx10.1} @tab @samp{.clwb} @tab @samp{.rdpid} @tab @samp{.ptwrite}
-@item @samp{.ibt} @tab @samp{.prefetchi} @tab @samp{.avx_ifma} @tab @samp{.avx_vnni_int8}
+@item @samp{.avx10.1} @tab @samp{.avx10.1aux} @tab @samp{.avx10.2} @tab @samp{.clwb}
+@item @samp{.rdpid} @tab @samp{.ptwrite} @tab @samp{.ibt} @tab @samp{.prefetchi}
 @item @samp{.cmpccxadd} @tab @samp{.wrmsrns} @tab @samp{.msrlist} @tab @samp{.se1}
 @item @samp{.avx_ne_convert} @tab @samp{.rao_int} @tab @samp{.fred} @tab @samp{.lkgs}
 @item @samp{.avx_vnni_int16} @tab @samp{.sha512} @tab @samp{.sm3} @tab @samp{.sm4}
-@item @samp{.pbndkb} @tab @samp{.user_msr} @tab @samp{.msr_imm} @tab @samp{.avx10.2}
-@item @samp{.movrs}
+@item @samp{.pbndkb} @tab @samp{.user_msr} @tab @samp{.msr_imm}
+@item @samp{.avx_ifma} @tab @samp{.avx_vnni_int8} @tab @samp{.movrs}
 @item @samp{.wbnoinvd} @tab @samp{.pconfig} @tab @samp{.waitpkg} @tab @samp{.cldemote}
 @item @samp{.shstk} @tab @samp{.gfni} @tab @samp{.vaes} @tab @samp{.vpclmulqdq}
 @item @samp{.movdiri} @tab @samp{.movdir64b} @tab @samp{.enqcmd} @tab @samp{.tsxldtrk}
--- /dev/null
+++ b/gas/testsuite/gas/i386/avx10.1-aux-256-cvt.d
@@ -0,0 +1,4 @@ 
+#name: i386 AVX10.1-aux/256 convert insns
+#as: -I${srcdir}/$subdir
+#objdump: -dw
+#dump: avx10_2-256-cvt.d
--- /dev/null
+++ b/gas/testsuite/gas/i386/avx10.1-aux-256-cvt.s
@@ -0,0 +1,6 @@ 
+# Check 32bit AVX10.1-aux/256 convert instructions
+
+	.arch generic32
+	.arch .avx10.1aux/256
+	.equ AVX10_V1_AUX, 1
+	.include "avx10_2-256-cvt.s"
--- /dev/null
+++ b/gas/testsuite/gas/i386/avx10.1-aux-256-media.l
@@ -0,0 +1,73 @@ 
+.*: Assembler messages:
+.*:39: Error: `vdpphps' is not supported .*
+.*:40: Error: `vdpphps' is not supported .*
+.*:41: Error: `vdpphps' is not supported .*
+.*:42: Error: `vdpphps' is not supported .*
+.*:43: Error: `vdpphps' is not supported .*
+.*:44: Error: `vdpphps' is not supported .*
+.*:45: Error: `vdpphps' is not supported .*
+.*:46: Error: `vdpphps' is not supported .*
+.*:47: Error: `vdpphps' is not supported .*
+.*:48: Error: `vdpphps' is not supported .*
+.*:50: Error:.* `vmpsadbw'.*
+.*:51: Error:.* `vmpsadbw'.*
+.*:52: Error:.* `vmpsadbw'.*
+.*:53: Error:.* `vmpsadbw'.*
+.*:54: Error:.* `vmpsadbw'.*
+.*:55: Error:.* `vmpsadbw'.*
+.*:56: Error:.* `vmpsadbw'.*
+.*:57: Error:.* `vmpsadbw'.*
+.*:58: Error:.* `vmpsadbw'.*
+.*:59: Error:.* `vmpsadbw'.*
+.*:93: Error: `vdpphps' is not supported .*
+.*:94: Error: `vdpphps' is not supported .*
+.*:95: Error: `vdpphps' is not supported .*
+.*:96: Error: `vdpphps' is not supported .*
+.*:97: Error: `vdpphps' is not supported .*
+.*:98: Error: `vdpphps' is not supported .*
+.*:99: Error: `vdpphps' is not supported .*
+.*:100: Error: `vdpphps' is not supported .*
+.*:101: Error: `vdpphps' is not supported .*
+.*:102: Error: `vdpphps' is not supported .*
+.*:104: Error:.* `vmpsadbw'.*
+.*:105: Error:.* `vmpsadbw'.*
+.*:106: Error:.* `vmpsadbw'.*
+.*:107: Error:.* `vmpsadbw'.*
+.*:108: Error:.* `vmpsadbw'.*
+.*:109: Error:.* `vmpsadbw'.*
+.*:110: Error:.* `vmpsadbw'.*
+.*:111: Error:.* `vmpsadbw'.*
+.*:112: Error:.* `vmpsadbw'.*
+.*:113: Error:.* `vmpsadbw'.*
+[ 	]*[0-9]+[ 	]+# Check .*
+#...
+[ 	]*[0-9]+[ 	]+>  \.irp .*
+[ 	]*[0-9]+[ 	]+\?+ 62F2572F 50F4[ 	]+>>  vpdpbssd %ymm4,%ymm5,%ymm6\{%k7\}
+#...
+[ 	]*[0-9]+[ 	]+\?+ 62F2572F 51F4[ 	]+>>  vpdpbssds %ymm4,%ymm5,%ymm6\{%k7\}
+#...
+[ 	]*[0-9]+[ 	]+>  \.irp .*
+[ 	]*[0-9]+[ 	]+\?+ 62F2562F 50F4[ 	]+>>  vpdpbsud %ymm4,%ymm5,%ymm6\{%k7\}
+#...
+[ 	]*[0-9]+[ 	]+\?+ 62F2562F 51F4[ 	]+>>  vpdpbsuds %ymm4,%ymm5,%ymm6\{%k7\}
+#...
+[ 	]*[0-9]+[ 	]+>  \.irp .*
+[ 	]*[0-9]+[ 	]+\?+ 62F2542F 50F4[ 	]+>>  vpdpbuud %ymm4,%ymm5,%ymm6\{%k7\}
+#...
+[ 	]*[0-9]+[ 	]+\?+ 62F2542F 51F4[ 	]+>>  vpdpbuuds %ymm4,%ymm5,%ymm6\{%k7\}
+#...
+[ 	]*[0-9]+[ 	]+>  \.irp .*
+[ 	]*[0-9]+[ 	]+\?+ 62F2562F D2F4[ 	]+>>  vpdpwsud %ymm4,%ymm5,%ymm6\{%k7\}
+#...
+[ 	]*[0-9]+[ 	]+\?+ 62F2562F D3F4[ 	]+>>  vpdpwsuds %ymm4,%ymm5,%ymm6\{%k7\}
+#...
+[ 	]*[0-9]+[ 	]+>  \.irp .*
+[ 	]*[0-9]+[ 	]+\?+ 62F2552F D2F4[ 	]+>>  vpdpwusd %ymm4,%ymm5,%ymm6\{%k7\}
+#...
+[ 	]*[0-9]+[ 	]+\?+ 62F2552F D3F4[ 	]+>>  vpdpwusds %ymm4,%ymm5,%ymm6\{%k7\}
+#...
+[ 	]*[0-9]+[ 	]+>  \.irp .*
+[ 	]*[0-9]+[ 	]+\?+ 62F2542F D2F4[ 	]+>>  vpdpwuud %ymm4,%ymm5,%ymm6\{%k7\}
+#...
+[ 	]*[0-9]+[ 	]+\?+ 62F2542F D3F4[ 	]+>>  vpdpwuuds %ymm4,%ymm5,%ymm6\{%k7\}
+#pass
--- /dev/null
+++ b/gas/testsuite/gas/i386/avx10.1-aux-256-media.s
@@ -0,0 +1,6 @@ 
+# Check 32bit AVX10.1-aux/256 media instructions
+
+	.arch generic32
+	.arch .avx10.1aux/256
+	.equ AVX10_V1_AUX, 1
+	.include "avx10_2-256-media.s"
--- /dev/null
+++ b/gas/testsuite/gas/i386/avx10.1-aux-512-cvt.d
@@ -0,0 +1,4 @@ 
+#name: i386 AVX10.1-aux/512 convert insns
+#as: -I${srcdir}/$subdir
+#objdump: -dw
+#dump: avx10_2-512-cvt.d
--- /dev/null
+++ b/gas/testsuite/gas/i386/avx10.1-aux-512-cvt.s
@@ -0,0 +1,6 @@ 
+# Check 32bit AVX10.1-aux/512 convert instructions
+
+	.arch generic32
+	.arch .avx10.1aux/512
+	.equ AVX10_V1_AUX, 1
+	.include "avx10_2-512-cvt.s"
--- /dev/null
+++ b/gas/testsuite/gas/i386/avx10.1-aux-512-media.l
@@ -0,0 +1,53 @@ 
+.*: Assembler messages:
+.*:29: Error: `vdpphps' is not supported .*
+.*:30: Error: `vdpphps' is not supported .*
+.*:31: Error: `vdpphps' is not supported .*
+.*:32: Error: `vdpphps' is not supported .*
+.*:33: Error: `vdpphps' is not supported .*
+.*:35: Error:.* `vmpsadbw'.*
+.*:36: Error:.* `vmpsadbw'.*
+.*:37: Error:.* `vmpsadbw'.*
+.*:38: Error:.* `vmpsadbw'.*
+.*:39: Error:.* `vmpsadbw'.*
+.*:63: Error: `vdpphps' is not supported .*
+.*:64: Error: `vdpphps' is not supported .*
+.*:65: Error: `vdpphps' is not supported .*
+.*:66: Error: `vdpphps' is not supported .*
+.*:67: Error: `vdpphps' is not supported .*
+.*:69: Error:.* `vmpsadbw'.*
+.*:70: Error:.* `vmpsadbw'.*
+.*:71: Error:.* `vmpsadbw'.*
+.*:72: Error:.* `vmpsadbw'.*
+.*:73: Error:.* `vmpsadbw'.*
+[ 	]*[0-9]+[ 	]+# Check .*
+#...
+[ 	]*[0-9]+[ 	]+>  \.irp .*
+[ 	]*[0-9]+[ 	]+\?+ 62F25748 50F4[ 	]+>>  vpdpbssd %zmm4,%zmm5,%zmm6
+#...
+[ 	]*[0-9]+[ 	]+\?+ 62F25748 51F4[ 	]+>>  vpdpbssds %zmm4,%zmm5,%zmm6
+#...
+[ 	]*[0-9]+[ 	]+>  \.irp .*
+[ 	]*[0-9]+[ 	]+\?+ 62F25648 50F4[ 	]+>>  vpdpbsud %zmm4,%zmm5,%zmm6
+#...
+[ 	]*[0-9]+[ 	]+\?+ 62F25648 51F4[ 	]+>>  vpdpbsuds %zmm4,%zmm5,%zmm6
+#...
+[ 	]*[0-9]+[ 	]+>  \.irp .*
+[ 	]*[0-9]+[ 	]+\?+ 62F25448 50F4[ 	]+>>  vpdpbuud %zmm4,%zmm5,%zmm6
+#...
+[ 	]*[0-9]+[ 	]+\?+ 62F25448 51F4[ 	]+>>  vpdpbuuds %zmm4,%zmm5,%zmm6
+#...
+[ 	]*[0-9]+[ 	]+>  \.irp .*
+[ 	]*[0-9]+[ 	]+\?+ 62F25648 D2F4[ 	]+>>  vpdpwsud %zmm4,%zmm5,%zmm6
+#...
+[ 	]*[0-9]+[ 	]+\?+ 62F25648 D3F4[ 	]+>>  vpdpwsuds %zmm4,%zmm5,%zmm6
+#...
+[ 	]*[0-9]+[ 	]+>  \.irp .*
+[ 	]*[0-9]+[ 	]+\?+ 62F25548 D2F4[ 	]+>>  vpdpwusd %zmm4,%zmm5,%zmm6
+#...
+[ 	]*[0-9]+[ 	]+\?+ 62F25548 D3F4[ 	]+>>  vpdpwusds %zmm4,%zmm5,%zmm6
+#...
+[ 	]*[0-9]+[ 	]+>  \.irp .*
+[ 	]*[0-9]+[ 	]+\?+ 62F25448 D2F4[ 	]+>>  vpdpwuud %zmm4,%zmm5,%zmm6
+#...
+[ 	]*[0-9]+[ 	]+\?+ 62F25448 D3F4[ 	]+>>  vpdpwuuds %zmm4,%zmm5,%zmm6
+#pass
--- /dev/null
+++ b/gas/testsuite/gas/i386/avx10.1-aux-512-media.s
@@ -0,0 +1,6 @@ 
+# Check 32bit AVX10.1-aux/512 media instructions
+
+	.arch generic32
+	.arch .avx10.1aux/512
+	.equ AVX10_V1_AUX, 1
+	.include "avx10_2-512-media.s"
--- a/gas/testsuite/gas/i386/avx10_2-256-cvt.s
+++ b/gas/testsuite/gas/i386/avx10_2-256-cvt.s
@@ -1,7 +1,9 @@ 
 # Check 32bit AVX10.2/256 instructions
 
+	.ifndef AVX10_V1_AUX
 	.arch generic32
 	.arch .avx10.2/256
+	.endif
 	.text
 _start:
 	vcvt2ps2phx	%xmm4, %xmm5, %xmm6
--- a/gas/testsuite/gas/i386/avx10_2-256-media.s
+++ b/gas/testsuite/gas/i386/avx10_2-256-media.s
@@ -1,7 +1,9 @@ 
 # Check 32bit AVX10.2/256 instructions
 
+	.ifndef AVX10_V1_AUX
 	.arch generic32
 	.arch .avx10.2/256
+	.endif
 	.text
 _start:
 	.irp m, ss, su, uu
--- a/gas/testsuite/gas/i386/avx10_2-512-cvt.s
+++ b/gas/testsuite/gas/i386/avx10_2-512-cvt.s
@@ -1,7 +1,9 @@ 
 # Check 32bit AVX10.2/512 instructions
 
+	.ifndef AVX10_V1_AUX
 	.arch generic32
 	.arch .avx10.2/512
+	.endif
 	.text
 _start:
 	vcvt2ps2phx	%zmm4, %zmm5, %zmm6
--- a/gas/testsuite/gas/i386/avx10_2-512-media.s
+++ b/gas/testsuite/gas/i386/avx10_2-512-media.s
@@ -1,7 +1,9 @@ 
 # Check 32bit AVX10.2/512 instructions
 
+	.ifndef AVX10_V1_AUX
 	.arch generic32
 	.arch .avx10.2/512
+	.endif
 	.text
 _start:
 	.irp m, ss, su, uu
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -521,6 +521,10 @@  if [gas_32_check] then {
     run_list_test "user_msr-inval"
     run_list_test "msr_imm-inval"
     run_list_test "apx-push2pop2-inval"
+    run_dump_test "avx10.1-aux-512-cvt"
+    run_dump_test "avx10.1-aux-256-cvt"
+    run_list_test "avx10.1-aux-512-media" "-I${srcdir}/$subdir -almn --divide --listing-lhs-width=2"
+    run_list_test "avx10.1-aux-256-media" "-I${srcdir}/$subdir -almn --divide --listing-lhs-width=2"
     run_dump_test "avx10_2-evex-promote"
     run_dump_test "avx10_2-512-media"
     run_dump_test "avx10_2-512-media-intel"
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -248,8 +248,10 @@  static const dependency isa_dependencies
   { "AVX10_1",
     "AVX512VL|AVX512DQ|AVX512CD|AVX512VBMI|AVX512_VBMI2|AVX512IFMA"
     "|AVX512_VNNI|AVX512_BF16|AVX512_FP16|AVX512_VPOPCNTDQ|AVX512_BITALG" },
-  { "AVX10_2",
+  { "AVX10_1_AUX",
     "AVX10_1" },
+  { "AVX10_2",
+    "AVX10_1_AUX" },
   { "SEV_ES",
     "SVME" },
   { "SNP",
@@ -451,6 +453,7 @@  static bitfield cpu_flags[] =
   BITFIELD (USER_MSR),
   BITFIELD (MSR_IMM),
   BITFIELD (APX_F),
+  BITFIELD (AVX10_1_AUX),
   BITFIELD (AVX10_2),
   BITFIELD (MOVRS),
   BITFIELD (MWAITX),
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -209,6 +209,8 @@  enum i386_cpu
   CpuAVX512_VP2INTERSECT,
   /* AMD AVX-512 BMM Instructions support required.  */
   CpuAVX512_BMM,
+  /* Intel AVX10.1-aux Instructions support required.  */
+  CpuAVX10_1_AUX,
   /* TDX Instructions support required.  */
   CpuTDX,
   /* Intel AVX VNNI Instructions support required.  */
@@ -509,6 +511,7 @@  typedef union i386_cpu_flags
       unsigned int cpuavx512_bf16:1;
       unsigned int cpuavx512_vp2intersect:1;
       unsigned int cpuavx512_bmm:1;
+      unsigned int cpuavx10_1_aux:1;
       unsigned int cputdx:1;
       unsigned int cpuavx_vnni:1;
       unsigned int cpuavx512_fp16:1;
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2969,7 +2969,7 @@  vpdpwssd<vnni><sat>, 0x6652|<sat:opc>, <
 
 <vnni:int8:int16:attr:reg:mem, +
   $y:_VNNI_INT8:_VNNI_INT16:Vex::, +
-  $z:10_2:10_2:Masking|Broadcast|Disp8ShiftVL:RegZMM:Dword>
+  $z:10_1_AUX:10_1_AUX:Masking|Broadcast|Disp8ShiftVL:RegZMM:Dword>
 
 // AVX-VNNI-INT8 instructions.
 
@@ -3537,12 +3537,9 @@  pop2p, 0x8f/0, APX_F, Modrm|VexW1|EVexMa
 
 // APX Push2/Pop2 instructions end.
 
-// AVX10.2 instructions.
+// AVX10.1-aux instructions.
 
-vdpphps, 0x52, AVX10_2, Modrm|Space0F38|Src1VVVV|VexW0|Masking|Broadcast|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegXMM|RegYMM|RegZMM|Dword|Unspecified|BaseIndex, RegXMM|RegYMM|RegZMM, RegXMM|RegYMM|RegZMM }
-vmpsadbw, 0xf342, AVX10_2, Modrm|Space0F3A|Src1VVVV|VexW0|Masking|Disp8ShiftVL|CheckOperandSize|NoSuf, { Imm8, RegXMM|RegYMM|RegZMM|Unspecified|BaseIndex, RegXMM|RegYMM|RegZMM, RegXMM|RegYMM|RegZMM }
-
-vcvt2ps2phx, 0x6667, AVX10_2, Modrm|Space0F38|Src1VVVV|VexW0|Masking|Broadcast|Disp8ShiftVL|CheckOperandSize|NoSuf|StaticRounding|SAE, { RegXMM|RegYMM|RegZMM|Dword|Unspecified|BaseIndex, RegXMM|RegYMM|RegZMM, RegXMM|RegYMM|RegZMM }
+vcvt2ps2phx, 0x6667, AVX10_1_AUX, Modrm|Space0F38|Src1VVVV|VexW0|Masking|Broadcast|Disp8ShiftVL|CheckOperandSize|NoSuf|StaticRounding|SAE, { RegXMM|RegYMM|RegZMM|Dword|Unspecified|BaseIndex, RegXMM|RegYMM|RegZMM, RegXMM|RegYMM|RegZMM }
 
 <cvt8:opc:spc, +
     bf8:74:Space0F38, +
@@ -3550,16 +3547,23 @@  vcvt2ps2phx, 0x6667, AVX10_2, Modrm|Spac
     hf8:18:Map5, +
     hf8s:1b:Map5>
 
-vcvtbiasph2<cvt8>, 0x<cvt8:opc>, AVX10_2, Modrm|<cvt8:spc>|Src1VVVV|VexW0|Masking|Broadcast|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegXMM|RegYMM|Word|Unspecified|BaseIndex, RegXMM|RegYMM, RegXMM }
-vcvtbiasph2<cvt8>, 0x<cvt8:opc>, AVX10_2, Modrm|<cvt8:spc>|EVex512|Src1VVVV|VexW0|Masking|Broadcast|Disp8MemShift=6|NoSuf, { RegZMM|Word|Unspecified|BaseIndex, RegZMM, RegYMM }
-vcvt2ph2<cvt8>, 0xf2<cvt8:opc>, AVX10_2, Modrm|<cvt8:spc>|Src1VVVV|VexW0|Masking|Broadcast|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegXMM|RegYMM|RegZMM|Word|Unspecified|BaseIndex, RegXMM|RegYMM|RegZMM, RegXMM|RegYMM|RegZMM }
-vcvtph2<cvt8><Exy>, 0xf3<cvt8:opc>, AVX10_2, Modrm|<cvt8:spc>|<Exy:attr>|VexW0|Masking|Broadcast|NoSuf, { <Exy:src>|Word, <Exy:dst> }
+vcvtbiasph2<cvt8>, 0x<cvt8:opc>, AVX10_1_AUX, Modrm|<cvt8:spc>|Src1VVVV|VexW0|Masking|Broadcast|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegXMM|RegYMM|Word|Unspecified|BaseIndex, RegXMM|RegYMM, RegXMM }
+vcvtbiasph2<cvt8>, 0x<cvt8:opc>, AVX10_1_AUX, Modrm|<cvt8:spc>|EVex512|Src1VVVV|VexW0|Masking|Broadcast|Disp8MemShift=6|NoSuf, { RegZMM|Word|Unspecified|BaseIndex, RegZMM, RegYMM }
+vcvt2ph2<cvt8>, 0xf2<cvt8:opc>, AVX10_1_AUX, Modrm|<cvt8:spc>|Src1VVVV|VexW0|Masking|Broadcast|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegXMM|RegYMM|RegZMM|Word|Unspecified|BaseIndex, RegXMM|RegYMM|RegZMM, RegXMM|RegYMM|RegZMM }
+vcvtph2<cvt8><Exy>, 0xf3<cvt8:opc>, AVX10_1_AUX, Modrm|<cvt8:spc>|<Exy:attr>|VexW0|Masking|Broadcast|NoSuf, { <Exy:src>|Word, <Exy:dst> }
 
 <cvt8>
 
-vcvthf82ph, 0xf21e, AVX10_2, Modrm|Map5|EVex128|VexW0|Masking|Disp8MemShift=3|NoSuf, { RegXMM|Qword|Unspecified|BaseIndex, RegXMM }
-vcvthf82ph, 0xf21e, AVX10_2, Modrm|Map5|EVex256|VexW0|Masking|Disp8MemShift=4|NoSuf, { RegXMM|Unspecified|BaseIndex, RegYMM }
-vcvthf82ph, 0xf21e, AVX10_2, Modrm|Map5|EVex512|VexW0|Masking|Disp8MemShift=5|NoSuf, { RegYMM|Unspecified|BaseIndex, RegZMM }
+vcvthf82ph, 0xf21e, AVX10_1_AUX, Modrm|Map5|EVex128|VexW0|Masking|Disp8MemShift=3|NoSuf, { RegXMM|Qword|Unspecified|BaseIndex, RegXMM }
+vcvthf82ph, 0xf21e, AVX10_1_AUX, Modrm|Map5|EVex256|VexW0|Masking|Disp8MemShift=4|NoSuf, { RegXMM|Unspecified|BaseIndex, RegYMM }
+vcvthf82ph, 0xf21e, AVX10_1_AUX, Modrm|Map5|EVex512|VexW0|Masking|Disp8MemShift=5|NoSuf, { RegYMM|Unspecified|BaseIndex, RegZMM }
+
+// AVX10.1-aux instructions end.
+
+// AVX10.2 instructions.
+
+vdpphps, 0x52, AVX10_2, Modrm|Space0F38|Src1VVVV|VexW0|Masking|Broadcast|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegXMM|RegYMM|RegZMM|Dword|Unspecified|BaseIndex, RegXMM|RegYMM|RegZMM, RegXMM|RegYMM|RegZMM }
+vmpsadbw, 0xf342, AVX10_2, Modrm|Space0F3A|Src1VVVV|VexW0|Masking|Disp8ShiftVL|CheckOperandSize|NoSuf, { Imm8, RegXMM|RegYMM|RegZMM|Unspecified|BaseIndex, RegXMM|RegYMM|RegZMM, RegXMM|RegYMM|RegZMM }
 
 v<fop>bf16, 0x66<fop:opc>, AVX10_2, Modrm|Map5|Src1VVVV|VexW0|Masking|Broadcast|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegXMM|RegYMM|RegZMM|Word|Unspecified|BaseIndex, RegXMM|RegYMM|RegZMM, RegXMM|RegYMM|RegZMM }