[v2] Support Intel AVX10.1

  Hi all,

Sorry for the patch delay since the hot discussion in GCC community in AVX10
last week occupied lots of my time.

I have just finished v2 patch for AVX10.1.

Changes in v2:

1. Added new attribute avx10_max_512bit to indicate 512 bit usage. The name is
aligned with the attribute used for GCC implementation. Since binutils uses
default on mode for attribute, I added check only when zmm is used or 64 bit
mask register instruction is used but not in the table.

I am open for the attribute name change or the implementation method change.

2. Removed 32 bit invalid test. 64 bit is enough. Also removed redundant
tests in x86-64-avx10_1.s

3. Added some comments and simpified the changes in gas/config/tc-i386.c.

This change is needed for AVX512_VP2INTERSECT table entry.

@@ -6382,7 +6400,9 @@ check_VecOperands (const insn_template *t)
   cpu = cpu_flags_and (t->cpu_flags, avx512);
   if (!cpu_flags_all_zero (&cpu)
       && !t->cpu_flags.bitfield.cpuavx512vl
-      && !cpu_arch_flags.bitfield.cpuavx512vl)
+      && !cpu_arch_flags.bitfield.cpuavx512vl
+      && (!t->cpu_flags.bitfield.cpuavx10_1
+         || !cpu_arch_flags.bitfield.cpuavx10_1))

Hope that I did not ignore something need to change in v1 patch. Thank for
your review.

Thx,
Haochen

gas/ChangeLog:

	* NEWS: Support Intel AVX10.1.
	* config/tc-i386.c
	(cpu_arch): Add avx10.1 and avx10_max_512bit.
	(cpu_flags_match): Handle AVX10.1 related instructions.
	(check_VecOperands): Ditto.
	(check_register): Allow zmm for avx10.1-512 and mask registers
	for avx10.1.
	* doc/c-i386.texi: Document .avx10.1 and .avx10_max_512bit.
	* testsuite/gas/i386/avx-ifma-inval.l: Add .noavx10.1.
	* testsuite/gas/i386/avx-ifma-inval.s: Ditto.
	* testsuite/gas/i386/avx-ifma.s: Ditto.
	* testsuite/gas/i386/avx-vnni-inval.l: Ditto.
	* testsuite/gas/i386/avx-vnni-inval.s: Ditto.
	* testsuite/gas/i386/avx-vnni.s: Ditto.
	* testsuite/gas/i386/noavx512-1.l: Ditto.
	* testsuite/gas/i386/noavx512-1.s: Ditto.
	* testsuite/gas/i386/noavx512-2.l: Ditto.
	* testsuite/gas/i386/noavx512-2.s: Ditto.
	* testsuite/gas/i386/x86-64-avx-ifma-inval.l: Ditto.
	* testsuite/gas/i386/x86-64-avx-ifma-inval.s: Ditto.
	* testsuite/gas/i386/x86-64-avx-vnni-inval.l: Ditto.
	* testsuite/gas/i386/x86-64-avx-vnni-inval.s: Ditto.
	* testsuite/gas/i386/xmmhi32.s: Ditto.
	* testsuite/gas/i386/x86-64.exp: Run AVX10.1 tests.
	* testsuite/gas/i386/x86-64-avx10_1-inval.d: Ditto.
	* testsuite/gas/i386/x86-64-avx10_1-inval.s: Ditto.
	* testsuite/gas/i386/x86-64-avx10_1.d: Ditto.
	* testsuite/gas/i386/x86-64-avx10_1.s: Ditto.

opcodes/ChangeLog:

	* i386-gen.c (isa_dependencies): Add AVX10_1 and
	AVX10_MAX_512BIT.
	(cpu_flags): Ditto.
	(output_i386_opcode): Add AVX10_1 in table for allowed
	instructions.
	* i386-init.h: Regenerated.
	* i386-opc.h (CpuAVX10_1, CpuAVX10_MAX_512BIT): New.
	(i386_cpu_flags): Add cpuavx10_1 and cpuavx10_max_512bit.
	* i386-init.h: Regenerated.
	* i386-tbl.h: Ditto.
---
 gas/NEWS                                      |     2 +
 gas/config/tc-i386.c                          |    43 +-
 gas/doc/c-i386.texi                           |     4 +-
 gas/testsuite/gas/i386/avx-ifma-inval.l       |     4 +-
 gas/testsuite/gas/i386/avx-ifma-inval.s       |     1 +
 gas/testsuite/gas/i386/avx-ifma.s             |     3 +
 gas/testsuite/gas/i386/avx-vnni-inval.l       |     4 +-
 gas/testsuite/gas/i386/avx-vnni-inval.s       |     1 +
 gas/testsuite/gas/i386/avx-vnni.s             |     3 +
 gas/testsuite/gas/i386/noavx512-1.l           |    39 +-
 gas/testsuite/gas/i386/noavx512-1.s           |     1 +
 gas/testsuite/gas/i386/noavx512-2.l           |   153 +-
 gas/testsuite/gas/i386/noavx512-2.s           |     1 +
 .../gas/i386/x86-64-avx-ifma-inval.l          |     4 +-
 .../gas/i386/x86-64-avx-ifma-inval.s          |     1 +
 .../gas/i386/x86-64-avx-vnni-inval.l          |     4 +-
 .../gas/i386/x86-64-avx-vnni-inval.s          |     1 +
 gas/testsuite/gas/i386/x86-64-avx10_1-inval.l |    20 +
 gas/testsuite/gas/i386/x86-64-avx10_1-inval.s |    27 +
 gas/testsuite/gas/i386/x86-64-avx10_1.d       |    54 +
 gas/testsuite/gas/i386/x86-64-avx10_1.s       |    50 +
 gas/testsuite/gas/i386/x86-64.exp             |     2 +
 gas/testsuite/gas/i386/xmmhi32.s              |     1 +
 opcodes/i386-gen.c                            |    25 +-
 opcodes/i386-init.h                           |   684 +-
 opcodes/i386-opc.h                            |     6 +
 opcodes/i386-tbl.h                            | 10436 ++++++++--------
 27 files changed, 5924 insertions(+), 5650 deletions(-)
 create mode 100644 gas/testsuite/gas/i386/x86-64-avx10_1-inval.l
 create mode 100644 gas/testsuite/gas/i386/x86-64-avx10_1-inval.s
 create mode 100644 gas/testsuite/gas/i386/x86-64-avx10_1.d
 create mode 100644 gas/testsuite/gas/i386/x86-64-avx10_1.s
  

On 14.08.2023 08:45, Haochen Jiang wrote:
> Changes in v2:
> 
> 1. Added new attribute avx10_max_512bit to indicate 512 bit usage. The name is
> aligned with the attribute used for GCC implementation. Since binutils uses
> default on mode for attribute, I added check only when zmm is used or 64 bit
> mask register instruction is used but not in the table.
> 
> I am open for the attribute name change or the implementation method change.
> 
> 2. Removed 32 bit invalid test. 64 bit is enough. Also removed redundant
> tests in x86-64-avx10_1.s
> 
> 3. Added some comments and simpified the changes in gas/config/tc-i386.c.
> 
> This change is needed for AVX512_VP2INTERSECT table entry.

Before I get into any details here, I'd like to understand why there still
is a new CpuAVX10_1 bit, when I had asked to drop it. I'm also concerned
of CpuAVX10_MAX_512BIT, when I did suggest a new attribute (i.e. a new
bitfield in struct i386_opcode_modifier), and then a more general purpose
one (so that by it being / becoming not just boolean it can later also be
used to deal with the - for now only theoretical - AVX10/128 case).

Jan
  

> Before I get into any details here, I'd like to understand why there still
> is a new CpuAVX10_1 bit, when I had asked to drop it. I'm also concerned

The reason is that we would like to keep the OR logic in the toolchain, which
means opening AVX10.1 but closing AVX512F should not disable the encoding.

But I just double think on that and get your point. GCC is using a default "off"
mode, if we are using OR logic, no code and current behavior are changed and
everything is natural and smooth. However, binutils is using a default "on"
mode, if we stick to OR logic just like GCC, it will eventually corrupt the current
behavior of .noavx512xxx, which could be a problem. I am slightly persuaded on
the proposal of setting and clearing bits of AVX512 for AVX10 in binutils.

H.J., what is your opinion?

> of CpuAVX10_MAX_512BIT, when I did suggest a new attribute (i.e. a new
> bitfield in struct i386_opcode_modifier), and then a more general purpose
> one (so that by it being / becoming not just boolean it can later also be
> used to deal with the - for now only theoretical - AVX10/128 case).

For question 2, I misunderstood the meaning of attribute. But I suppose
AVX10/128 is too theoretical to be true. I will make it a boolean for now.

Thx,
Haochen

> 
> Jan
  

On 14.08.2023 10:46, Jiang, Haochen wrote:
>> Before I get into any details here, I'd like to understand why there still
>> is a new CpuAVX10_1 bit, when I had asked to drop it. I'm also concerned
> 
> The reason is that we would like to keep the OR logic in the toolchain, which
> means opening AVX10.1 but closing AVX512F should not disable the encoding.
> 
> But I just double think on that and get your point. GCC is using a default "off"
> mode, if we are using OR logic, no code and current behavior are changed and
> everything is natural and smooth. However, binutils is using a default "on"
> mode, if we stick to OR logic just like GCC, it will eventually corrupt the current
> behavior of .noavx512xxx, which could be a problem. I am slightly persuaded on
> the proposal of setting and clearing bits of AVX512 for AVX10 in binutils.

The primary indication of things being done the wrong way is the need to
add several ".arch .noavx10.1" in the testsuite. Whatever the final
solution, this should not be necessary (because it indicates people may
also need to change their code then, if they want a guarantee that no
512-bit insns are used).

>> of CpuAVX10_MAX_512BIT, when I did suggest a new attribute (i.e. a new
>> bitfield in struct i386_opcode_modifier), and then a more general purpose
>> one (so that by it being / becoming not just boolean it can later also be
>> used to deal with the - for now only theoretical - AVX10/128 case).
> 
> For question 2, I misunderstood the meaning of attribute. But I suppose
> AVX10/128 is too theoretical to be true. I will make it a boolean for now.

Right, a boolean is fine initially, but with the spec explicitly allowing
the 128-bits-only mode, I'm pretty sure we ought to support that rather
sooner than later. After all, more artificial environments (emulators,
virtualization) may expose feature combinations not ever seen on real
hardware.

Jan
  

On 14.08.2023 12:33, Jan Beulich via Binutils wrote:
> On 14.08.2023 10:46, Jiang, Haochen wrote:
>> For question 2, I misunderstood the meaning of attribute. But I suppose
>> AVX10/128 is too theoretical to be true. I will make it a boolean for now.
> 
> Right, a boolean is fine initially, but with the spec explicitly allowing
> the 128-bits-only mode, I'm pretty sure we ought to support that rather
> sooner than later. After all, more artificial environments (emulators,
> virtualization) may expose feature combinations not ever seen on real
> hardware.

Actually, making it a boolean isn't nice, because a boolean would be named
differently than a numeric field. So I think it wants to be numeric, but
with only 0 and one other value permitted for now.

Jan
  

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Monday, August 14, 2023 6:34 PM
> To: Jiang, Haochen <haochen.jiang@intel.com>
> Cc: binutils@sourceware.org; hjl.tools@gmail.com
> Subject: Re: [PATCH v2] Support Intel AVX10.1
> 
> On 14.08.2023 10:46, Jiang, Haochen wrote:
> >> Before I get into any details here, I'd like to understand why there
> >> still is a new CpuAVX10_1 bit, when I had asked to drop it. I'm also
> >> concerned
> >
> > The reason is that we would like to keep the OR logic in the
> > toolchain, which means opening AVX10.1 but closing AVX512F should not
> disable the encoding.
> >
> > But I just double think on that and get your point. GCC is using a default "off"
> > mode, if we are using OR logic, no code and current behavior are
> > changed and everything is natural and smooth. However, binutils is using a
> default "on"
> > mode, if we stick to OR logic just like GCC, it will eventually
> > corrupt the current behavior of .noavx512xxx, which could be a
> > problem. I am slightly persuaded on the proposal of setting and clearing bits
> of AVX512 for AVX10 in binutils.
> 
> The primary indication of things being done the wrong way is the need to add
> several ".arch .noavx10.1" in the testsuite. Whatever the final solution, this
> should not be necessary (because it indicates people may also need to change
> their code then, if they want a guarantee that no 512-bit insns are used).
> 

I have an open after digging into .arch directives corner cases when we choose
to set/clear bits for AVX512 in AVX10.1.

Should directives like .noavx512f .avx10.1 open zmm registers? For directive
.noavx512fp16 .avx10.1, should we enable zmm registers for AVX512FP16 insts?

> >> of CpuAVX10_MAX_512BIT, when I did suggest a new attribute (i.e. a
> >> new bitfield in struct i386_opcode_modifier), and then a more general
> >> purpose one (so that by it being / becoming not just boolean it can
> >> later also be used to deal with the - for now only theoretical - AVX10/128
> case).
> >
> > For question 2, I misunderstood the meaning of attribute. But I
> > suppose
> > AVX10/128 is too theoretical to be true. I will make it a boolean for now.
> 
> Right, a boolean is fine initially, but with the spec explicitly allowing the 128-
> bits-only mode, I'm pretty sure we ought to support that rather sooner than
> later. After all, more artificial environments (emulators,
> virtualization) may expose feature combinations not ever seen on real
> hardware.

After I think twice on that, I suppose maybe it is not that appropriate to put it
into i386_opcode_modifier since in AVX10, the vector width is depends on CPU.
I suppose i386_opcode_modifier is a feature for instructions but not CPU.

Thx,
Haochen

> 
> Jan
  

On 15.08.2023 10:32, Jiang, Haochen wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Monday, August 14, 2023 6:34 PM
>> To: Jiang, Haochen <haochen.jiang@intel.com>
>> Cc: binutils@sourceware.org; hjl.tools@gmail.com
>> Subject: Re: [PATCH v2] Support Intel AVX10.1
>>
>> On 14.08.2023 10:46, Jiang, Haochen wrote:
>>>> Before I get into any details here, I'd like to understand why there
>>>> still is a new CpuAVX10_1 bit, when I had asked to drop it. I'm also
>>>> concerned
>>>
>>> The reason is that we would like to keep the OR logic in the
>>> toolchain, which means opening AVX10.1 but closing AVX512F should not
>> disable the encoding.
>>>
>>> But I just double think on that and get your point. GCC is using a default "off"
>>> mode, if we are using OR logic, no code and current behavior are
>>> changed and everything is natural and smooth. However, binutils is using a
>> default "on"
>>> mode, if we stick to OR logic just like GCC, it will eventually
>>> corrupt the current behavior of .noavx512xxx, which could be a
>>> problem. I am slightly persuaded on the proposal of setting and clearing bits
>> of AVX512 for AVX10 in binutils.
>>
>> The primary indication of things being done the wrong way is the need to add
>> several ".arch .noavx10.1" in the testsuite. Whatever the final solution, this
>> should not be necessary (because it indicates people may also need to change
>> their code then, if they want a guarantee that no 512-bit insns are used).
>>
> 
> I have an open after digging into .arch directives corner cases when we choose
> to set/clear bits for AVX512 in AVX10.1.
> 
> Should directives like .noavx512f .avx10.1 open zmm registers?

You mean the combination of the two, in that order? Yes, of course.

> For directive
> .noavx512fp16 .avx10.1, should we enable zmm registers for AVX512FP16 insts?

And then yes here, too.

In both cases what remains to be determined is how vector size is to
be limited. I think that wants to be independent of the .avx10.<N>.

>>>> of CpuAVX10_MAX_512BIT, when I did suggest a new attribute (i.e. a
>>>> new bitfield in struct i386_opcode_modifier), and then a more general
>>>> purpose one (so that by it being / becoming not just boolean it can
>>>> later also be used to deal with the - for now only theoretical - AVX10/128
>> case).
>>>
>>> For question 2, I misunderstood the meaning of attribute. But I
>>> suppose
>>> AVX10/128 is too theoretical to be true. I will make it a boolean for now.
>>
>> Right, a boolean is fine initially, but with the spec explicitly allowing the 128-
>> bits-only mode, I'm pretty sure we ought to support that rather sooner than
>> later. After all, more artificial environments (emulators,
>> virtualization) may expose feature combinations not ever seen on real
>> hardware.
> 
> After I think twice on that, I suppose maybe it is not that appropriate to put it
> into i386_opcode_modifier since in AVX10, the vector width is depends on CPU.
> I suppose i386_opcode_modifier is a feature for instructions but not CPU.

I disagree. See the uses of EVex, for example. As said above, I think
maximum vector width and ISA extensions want dealing with separately,
and only the latter would generally qualify for Cpu* flags. Furthermore
recall that the attribute wants widening sooner or later, and Cpu*
flags are uniformly boolean. Only attributes may have numeric values.

Jan
  

> > I have an open after digging into .arch directives corner cases when we choose
> > to set/clear bits for AVX512 in AVX10.1.
> >
> > Should directives like .noavx512f .avx10.1 open zmm registers?
> 
> You mean the combination of the two, in that order? Yes, of course.
> 
> > For directive
> > .noavx512fp16 .avx10.1, should we enable zmm registers for AVX512FP16 insts?
> 
> And then yes here, too.
> 
> In both cases what remains to be determined is how vector size is to
> be limited. I think that wants to be independent of the .avx10.<N>.
> 

That also met my expectation. And it will make everything easy to
understand.

> >> Right, a boolean is fine initially, but with the spec explicitly allowing the 128-
> >> bits-only mode, I'm pretty sure we ought to support that rather sooner than
> >> later. After all, more artificial environments (emulators,
> >> virtualization) may expose feature combinations not ever seen on real
> >> hardware.
> >
> > After I think twice on that, I suppose maybe it is not that appropriate to put it
> > into i386_opcode_modifier since in AVX10, the vector width is depends on CPU.
> > I suppose i386_opcode_modifier is a feature for instructions but not CPU.
> 
> I disagree. See the uses of EVex, for example. As said above, I think
> maximum vector width and ISA extensions want dealing with separately,
> and only the latter would generally qualify for Cpu* flags. Furthermore
> recall that the attribute wants widening sooner or later, and Cpu*
> flags are uniformly boolean. Only attributes may have numeric values.

After I checked code, I still miss the point here.

My concern is how to actually disable the zmm registers for AVX10/256
and ymm registers for theoretical AVX10/128. I suppose i386_opcode_modifier
is more related to building up the whole encoding. But each AVX10.X/256 is an
actual arch.

Adding a feature in i386_opcode_modifier can indicate what is the maximum
vector length the instruction is allowed on all archs but has nothing to do with
disabling zmm registers on an 256-bit only arch.

I might be wrong on the understanding on what to add in i386_opcode_modifier.
Please just correct if there is something wrong.

Thx,
Haochen

> 
> Jan
  

On 16.08.2023 10:21, Jiang, Haochen wrote:
>>> After I think twice on that, I suppose maybe it is not that appropriate to put it
>>> into i386_opcode_modifier since in AVX10, the vector width is depends on CPU.
>>> I suppose i386_opcode_modifier is a feature for instructions but not CPU.
>>
>> I disagree. See the uses of EVex, for example. As said above, I think
>> maximum vector width and ISA extensions want dealing with separately,
>> and only the latter would generally qualify for Cpu* flags. Furthermore
>> recall that the attribute wants widening sooner or later, and Cpu*
>> flags are uniformly boolean. Only attributes may have numeric values.
> 
> After I checked code, I still miss the point here.
> 
> My concern is how to actually disable the zmm registers for AVX10/256
> and ymm registers for theoretical AVX10/128.

That's the easy part: That'll want doing in check_register(). The issue
is with insns which do 512-bit operation despite not using zmm registers
(think of vfpclassp* with memory operand).

> I suppose i386_opcode_modifier
> is more related to building up the whole encoding. But each AVX10.X/256 is an
> actual arch.

I wouldn't agree with the last sentence, but ...

> Adding a feature in i386_opcode_modifier can indicate what is the maximum
> vector length the instruction is allowed on all archs but has nothing to do with
> disabling zmm registers on an 256-bit only arch.

... you still have a point here. Maybe it only wants to be a boolean,
indicating that an insn is vector-length sensitive. Yet re-using the
EVex attribute continues to be an option: With vector length
constrained to 256 (or 128) bits, EVEX512 (or EVEX256) simply become
unavailable for encoding, and EVEXDYN would be equally constrained.
And if re-using that attribute continues to be an option, adding a
new non-boolean attribute clearly is also possible.

So I guess there may have been a slight misunderstanding: I was
suggesting an attribute expressing permissible vector lengths (hence
the consideration of re-using EVex), which would then be checked
against the established (through whatever directive / command line
option) maximum vector length. I did not suggest a new "max vector
length" attribute.

Jan
  

On 16.08.2023 10:59, Jan Beulich via Binutils wrote:
> On 16.08.2023 10:21, Jiang, Haochen wrote:
>>>> After I think twice on that, I suppose maybe it is not that appropriate to put it
>>>> into i386_opcode_modifier since in AVX10, the vector width is depends on CPU.
>>>> I suppose i386_opcode_modifier is a feature for instructions but not CPU.
>>>
>>> I disagree. See the uses of EVex, for example. As said above, I think
>>> maximum vector width and ISA extensions want dealing with separately,
>>> and only the latter would generally qualify for Cpu* flags. Furthermore
>>> recall that the attribute wants widening sooner or later, and Cpu*
>>> flags are uniformly boolean. Only attributes may have numeric values.
>>
>> After I checked code, I still miss the point here.
>>
>> My concern is how to actually disable the zmm registers for AVX10/256
>> and ymm registers for theoretical AVX10/128.
> 
> That's the easy part: That'll want doing in check_register(). The issue
> is with insns which do 512-bit operation despite not using zmm registers
> (think of vfpclassp* with memory operand).
> 
>> I suppose i386_opcode_modifier
>> is more related to building up the whole encoding. But each AVX10.X/256 is an
>> actual arch.
> 
> I wouldn't agree with the last sentence, but ...
> 
>> Adding a feature in i386_opcode_modifier can indicate what is the maximum
>> vector length the instruction is allowed on all archs but has nothing to do with
>> disabling zmm registers on an 256-bit only arch.
> 
> ... you still have a point here. Maybe it only wants to be a boolean,
> indicating that an insn is vector-length sensitive. Yet re-using the
> EVex attribute continues to be an option: With vector length
> constrained to 256 (or 128) bits, EVEX512 (or EVEX256) simply become
> unavailable for encoding, and EVEXDYN would be equally constrained.
> And if re-using that attribute continues to be an option, adding a
> new non-boolean attribute clearly is also possible.
> 
> So I guess there may have been a slight misunderstanding: I was
> suggesting an attribute expressing permissible vector lengths (hence
> the consideration of re-using EVex), which would then be checked
> against the established (through whatever directive / command line
> option) maximum vector length. I did not suggest a new "max vector
> length" attribute.

Just to mention it: I've meanwhile realized that re-using EVex here will
collide with APX introducing EVEX-encoded KMOV*. So it'll need to be a
very similar but distinct attribute. And if it turned out that the
attribute then is really only needed on the mask insns (using EVex
elsewhere), it could equally well be a "permitted vector lengths" or a
"maximum vector length" one, as both are then equal. Question is what
AVX10/128 would mean for VEX-encoded insns. It seems likely that 256-bit
forms wouldn't be permitted there either then, in which case applicable
VEX-encoded insns would then need to gain such attributes as well. In
that case it would of course be more logical to stick to "permitted
vector lengths".

Jan
  

On 17.08.2023 11:08, Jan Beulich via Binutils wrote:
> On 16.08.2023 10:59, Jan Beulich via Binutils wrote:
>> On 16.08.2023 10:21, Jiang, Haochen wrote:
>>>>> After I think twice on that, I suppose maybe it is not that appropriate to put it
>>>>> into i386_opcode_modifier since in AVX10, the vector width is depends on CPU.
>>>>> I suppose i386_opcode_modifier is a feature for instructions but not CPU.
>>>>
>>>> I disagree. See the uses of EVex, for example. As said above, I think
>>>> maximum vector width and ISA extensions want dealing with separately,
>>>> and only the latter would generally qualify for Cpu* flags. Furthermore
>>>> recall that the attribute wants widening sooner or later, and Cpu*
>>>> flags are uniformly boolean. Only attributes may have numeric values.
>>>
>>> After I checked code, I still miss the point here.
>>>
>>> My concern is how to actually disable the zmm registers for AVX10/256
>>> and ymm registers for theoretical AVX10/128.
>>
>> That's the easy part: That'll want doing in check_register(). The issue
>> is with insns which do 512-bit operation despite not using zmm registers
>> (think of vfpclassp* with memory operand).
>>
>>> I suppose i386_opcode_modifier
>>> is more related to building up the whole encoding. But each AVX10.X/256 is an
>>> actual arch.
>>
>> I wouldn't agree with the last sentence, but ...
>>
>>> Adding a feature in i386_opcode_modifier can indicate what is the maximum
>>> vector length the instruction is allowed on all archs but has nothing to do with
>>> disabling zmm registers on an 256-bit only arch.
>>
>> ... you still have a point here. Maybe it only wants to be a boolean,
>> indicating that an insn is vector-length sensitive. Yet re-using the
>> EVex attribute continues to be an option: With vector length
>> constrained to 256 (or 128) bits, EVEX512 (or EVEX256) simply become
>> unavailable for encoding, and EVEXDYN would be equally constrained.
>> And if re-using that attribute continues to be an option, adding a
>> new non-boolean attribute clearly is also possible.
>>
>> So I guess there may have been a slight misunderstanding: I was
>> suggesting an attribute expressing permissible vector lengths (hence
>> the consideration of re-using EVex), which would then be checked
>> against the established (through whatever directive / command line
>> option) maximum vector length. I did not suggest a new "max vector
>> length" attribute.
> 
> Just to mention it: I've meanwhile realized that re-using EVex here will
> collide with APX introducing EVEX-encoded KMOV*. So it'll need to be a
> very similar but distinct attribute. And if it turned out that the
> attribute then is really only needed on the mask insns (using EVex
> elsewhere), it could equally well be a "permitted vector lengths" or a
> "maximum vector length" one, as both are then equal. Question is what
> AVX10/128 would mean for VEX-encoded insns. It seems likely that 256-bit
> forms wouldn't be permitted there either then, in which case applicable
> VEX-encoded insns would then need to gain such attributes as well. In
> that case it would of course be more logical to stick to "permitted
> vector lengths".

Sorry, yet another update. For one it can't be "maximum", but only
"minimum". And I meanwhile think "permitted" along the lines of EVex
won't catch it either. I guess I will want to take a stab myself ...

Jan
  

On 14.08.2023 08:45, Haochen Jiang wrote:
> @@ -1315,6 +1321,20 @@ output_i386_opcode (FILE *table, const char *name, char *str,
>    ident = mkident (name);
>    fprintf (table, "  { MN_%s, 0x%0*llx%s, %u,",
>  	   ident, 2 * (int)length, opcode, end, i);
> +
> +  j = strlen(ident);
> +  /* All AVX512F based instructions are usable for AVX10.1 except
> +     AVX512PF/ER/4FMAPS/4VNNIW/VP2INTERSECT.  */
> +  if (strstr (cpu_flags, "AVX512")
> +      && !strstr (cpu_flags, "AVX512PF")
> +      && !strstr (cpu_flags, "AVX512ER")
> +      && !strstr (cpu_flags, "4FMAPS")
> +      && !strstr (cpu_flags, "4VNNIW")
> +      && !strstr (cpu_flags, "VP2INTERSECT"))
> +    {
> +      cpu_flags = concat (cpu_flags, "|AVX10_1", NULL);
> +      k = 1;
> +    }
>    free (ident);

While making a patch myself along the lines of what I had outlined, I came
to realize that the above isn't enough. (I'm pretty sure I wouldn't have
spotted this by merely reviewing your patch.) This may be a result of the
spec being somewhat ambiguous when it comes to GFNI, VAES, and VPCLMULQDQ.
There's a note there saying something about the respective EVEX encodings.
But that still requires the VEX encodings connected to these three
features to also become suitably available. While this works fine for
GFNI, it doesn't for the other two: The 128-bit VEX encodings, which
surely are available when the 256-bit ones are, would become impossible
to use. The assembler would pick the (larger) EVEX forms instead. There
are two ways to solve this that I can see right away:
1) AES becomes a dependency of VAES (and PCLMULQDQ one of VPCLMULQDQ)
2) We put in place extra templates.
I'm wary of the first option as long as not at least informally supported
by you (Intel). Hence I went with option 2 for now.

I'm only done with the /512 patch, so I won't post right away. I'm still
debating with myself whether to control maximum vector length via a new
directive, or via a special form of .arch.

Jan
  

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, August 18, 2023 9:03 PM
> To: Jiang, Haochen <haochen.jiang@intel.com>
> Cc: hjl.tools@gmail.com; binutils@sourceware.org
> Subject: Re: [PATCH v2] Support Intel AVX10.1
> 
> On 14.08.2023 08:45, Haochen Jiang wrote:
> > @@ -1315,6 +1321,20 @@ output_i386_opcode (FILE *table, const char
> *name, char *str,
> >    ident = mkident (name);
> >    fprintf (table, "  { MN_%s, 0x%0*llx%s, %u,",
> >  	   ident, 2 * (int)length, opcode, end, i);
> > +
> > +  j = strlen(ident);
> > +  /* All AVX512F based instructions are usable for AVX10.1 except
> > +     AVX512PF/ER/4FMAPS/4VNNIW/VP2INTERSECT.  */  if (strstr
> > + (cpu_flags, "AVX512")
> > +      && !strstr (cpu_flags, "AVX512PF")
> > +      && !strstr (cpu_flags, "AVX512ER")
> > +      && !strstr (cpu_flags, "4FMAPS")
> > +      && !strstr (cpu_flags, "4VNNIW")
> > +      && !strstr (cpu_flags, "VP2INTERSECT"))
> > +    {
> > +      cpu_flags = concat (cpu_flags, "|AVX10_1", NULL);
> > +      k = 1;
> > +    }
> >    free (ident);
> 
> While making a patch myself along the lines of what I had outlined, I came to
> realize that the above isn't enough. (I'm pretty sure I wouldn't have spotted
> this by merely reviewing your patch.) This may be a result of the spec being
> somewhat ambiguous when it comes to GFNI, VAES, and VPCLMULQDQ.
> There's a note there saying something about the respective EVEX encodings.
> But that still requires the VEX encodings connected to these three features to
> also become suitably available. While this works fine for GFNI, it doesn't for
> the other two: The 128-bit VEX encodings, which surely are available when the
> 256-bit ones are, would become impossible to use. The assembler would pick
> the (larger) EVEX forms instead. There are two ways to solve this that I can see
> right away:
> 1) AES becomes a dependency of VAES (and PCLMULQDQ one of
> VPCLMULQDQ)
> 2) We put in place extra templates.
> I'm wary of the first option as long as not at least informally supported by you
> (Intel). Hence I went with option 2 for now.
> 
> I'm only done with the /512 patch, so I won't post right away. I'm still
> debating with myself whether to control maximum vector length via a new
> directive, or via a special form of .arch.

Hi Jan,

Do you think a command line option like -mavx10maxvl=256/512 with default 512
is ok for this scenario? I am working to revise the AVX10.1 patch like that.

Thx,
Haochen

> 
> Jan
  

On 23.08.2023 04:20, Jiang, Haochen wrote:
> 
> 
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, August 18, 2023 9:03 PM
>> To: Jiang, Haochen <haochen.jiang@intel.com>
>> Cc: hjl.tools@gmail.com; binutils@sourceware.org
>> Subject: Re: [PATCH v2] Support Intel AVX10.1
>>
>> On 14.08.2023 08:45, Haochen Jiang wrote:
>>> @@ -1315,6 +1321,20 @@ output_i386_opcode (FILE *table, const char
>> *name, char *str,
>>>    ident = mkident (name);
>>>    fprintf (table, "  { MN_%s, 0x%0*llx%s, %u,",
>>>  	   ident, 2 * (int)length, opcode, end, i);
>>> +
>>> +  j = strlen(ident);
>>> +  /* All AVX512F based instructions are usable for AVX10.1 except
>>> +     AVX512PF/ER/4FMAPS/4VNNIW/VP2INTERSECT.  */  if (strstr
>>> + (cpu_flags, "AVX512")
>>> +      && !strstr (cpu_flags, "AVX512PF")
>>> +      && !strstr (cpu_flags, "AVX512ER")
>>> +      && !strstr (cpu_flags, "4FMAPS")
>>> +      && !strstr (cpu_flags, "4VNNIW")
>>> +      && !strstr (cpu_flags, "VP2INTERSECT"))
>>> +    {
>>> +      cpu_flags = concat (cpu_flags, "|AVX10_1", NULL);
>>> +      k = 1;
>>> +    }
>>>    free (ident);
>>
>> While making a patch myself along the lines of what I had outlined, I came to
>> realize that the above isn't enough. (I'm pretty sure I wouldn't have spotted
>> this by merely reviewing your patch.) This may be a result of the spec being
>> somewhat ambiguous when it comes to GFNI, VAES, and VPCLMULQDQ.
>> There's a note there saying something about the respective EVEX encodings.
>> But that still requires the VEX encodings connected to these three features to
>> also become suitably available. While this works fine for GFNI, it doesn't for
>> the other two: The 128-bit VEX encodings, which surely are available when the
>> 256-bit ones are, would become impossible to use. The assembler would pick
>> the (larger) EVEX forms instead. There are two ways to solve this that I can see
>> right away:
>> 1) AES becomes a dependency of VAES (and PCLMULQDQ one of
>> VPCLMULQDQ)
>> 2) We put in place extra templates.
>> I'm wary of the first option as long as not at least informally supported by you
>> (Intel). Hence I went with option 2 for now.
>>
>> I'm only done with the /512 patch, so I won't post right away. I'm still
>> debating with myself whether to control maximum vector length via a new
>> directive, or via a special form of .arch.
> 
> Do you think a command line option like -mavx10maxvl=256/512 with default 512
> is ok for this scenario? I am working to revise the AVX10.1 patch like that.

That's certainly an option, but right now I have different plans.

Jan
  

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, August 23, 2023 1:54 PM
> To: Jiang, Haochen <haochen.jiang@intel.com>
> Cc: hjl.tools@gmail.com; binutils@sourceware.org
> Subject: Re: [PATCH v2] Support Intel AVX10.1
> 
> On 23.08.2023 04:20, Jiang, Haochen wrote:
> >
> >
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Friday, August 18, 2023 9:03 PM
> >> To: Jiang, Haochen <haochen.jiang@intel.com>
> >> Cc: hjl.tools@gmail.com; binutils@sourceware.org
> >> Subject: Re: [PATCH v2] Support Intel AVX10.1
> >>
> >> On 14.08.2023 08:45, Haochen Jiang wrote:
> >>> @@ -1315,6 +1321,20 @@ output_i386_opcode (FILE *table, const char
> >> *name, char *str,
> >>>    ident = mkident (name);
> >>>    fprintf (table, "  { MN_%s, 0x%0*llx%s, %u,",
> >>>  	   ident, 2 * (int)length, opcode, end, i);
> >>> +
> >>> +  j = strlen(ident);
> >>> +  /* All AVX512F based instructions are usable for AVX10.1 except
> >>> +     AVX512PF/ER/4FMAPS/4VNNIW/VP2INTERSECT.  */  if (strstr
> >>> + (cpu_flags, "AVX512")
> >>> +      && !strstr (cpu_flags, "AVX512PF")
> >>> +      && !strstr (cpu_flags, "AVX512ER")
> >>> +      && !strstr (cpu_flags, "4FMAPS")
> >>> +      && !strstr (cpu_flags, "4VNNIW")
> >>> +      && !strstr (cpu_flags, "VP2INTERSECT"))
> >>> +    {
> >>> +      cpu_flags = concat (cpu_flags, "|AVX10_1", NULL);
> >>> +      k = 1;
> >>> +    }
> >>>    free (ident);
> >>
> >> While making a patch myself along the lines of what I had outlined, I
> >> came to realize that the above isn't enough. (I'm pretty sure I
> >> wouldn't have spotted this by merely reviewing your patch.) This may
> >> be a result of the spec being somewhat ambiguous when it comes to GFNI,
> VAES, and VPCLMULQDQ.
> >> There's a note there saying something about the respective EVEX
> encodings.
> >> But that still requires the VEX encodings connected to these three
> >> features to also become suitably available. While this works fine for
> >> GFNI, it doesn't for the other two: The 128-bit VEX encodings, which
> >> surely are available when the 256-bit ones are, would become
> >> impossible to use. The assembler would pick the (larger) EVEX forms
> >> instead. There are two ways to solve this that I can see right away:
> >> 1) AES becomes a dependency of VAES (and PCLMULQDQ one of
> >> VPCLMULQDQ)
> >> 2) We put in place extra templates.
> >> I'm wary of the first option as long as not at least informally
> >> supported by you (Intel). Hence I went with option 2 for now.
> >>
> >> I'm only done with the /512 patch, so I won't post right away. I'm
> >> still debating with myself whether to control maximum vector length
> >> via a new directive, or via a special form of .arch.
> >
> > Do you think a command line option like -mavx10maxvl=256/512 with
> > default 512 is ok for this scenario? I am working to revise the AVX10.1 patch
> like that.
> 
> That's certainly an option, but right now I have different plans.

Actually all the three options are ok for me, they should not be that complex
based on the current part of v3 patch setting/clearing AVX512 bit for AVX10.1.

Thx,
Haochen

> 
> Jan
  

On 23.08.2023 08:21, Jiang, Haochen wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Wednesday, August 23, 2023 1:54 PM
>> To: Jiang, Haochen <haochen.jiang@intel.com>
>> Cc: hjl.tools@gmail.com; binutils@sourceware.org
>> Subject: Re: [PATCH v2] Support Intel AVX10.1
>>
>> On 23.08.2023 04:20, Jiang, Haochen wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Friday, August 18, 2023 9:03 PM
>>>> To: Jiang, Haochen <haochen.jiang@intel.com>
>>>> Cc: hjl.tools@gmail.com; binutils@sourceware.org
>>>> Subject: Re: [PATCH v2] Support Intel AVX10.1
>>>>
>>>> On 14.08.2023 08:45, Haochen Jiang wrote:
>>>>> @@ -1315,6 +1321,20 @@ output_i386_opcode (FILE *table, const char
>>>> *name, char *str,
>>>>>    ident = mkident (name);
>>>>>    fprintf (table, "  { MN_%s, 0x%0*llx%s, %u,",
>>>>>  	   ident, 2 * (int)length, opcode, end, i);
>>>>> +
>>>>> +  j = strlen(ident);
>>>>> +  /* All AVX512F based instructions are usable for AVX10.1 except
>>>>> +     AVX512PF/ER/4FMAPS/4VNNIW/VP2INTERSECT.  */  if (strstr
>>>>> + (cpu_flags, "AVX512")
>>>>> +      && !strstr (cpu_flags, "AVX512PF")
>>>>> +      && !strstr (cpu_flags, "AVX512ER")
>>>>> +      && !strstr (cpu_flags, "4FMAPS")
>>>>> +      && !strstr (cpu_flags, "4VNNIW")
>>>>> +      && !strstr (cpu_flags, "VP2INTERSECT"))
>>>>> +    {
>>>>> +      cpu_flags = concat (cpu_flags, "|AVX10_1", NULL);
>>>>> +      k = 1;
>>>>> +    }
>>>>>    free (ident);
>>>>
>>>> While making a patch myself along the lines of what I had outlined, I
>>>> came to realize that the above isn't enough. (I'm pretty sure I
>>>> wouldn't have spotted this by merely reviewing your patch.) This may
>>>> be a result of the spec being somewhat ambiguous when it comes to GFNI,
>> VAES, and VPCLMULQDQ.
>>>> There's a note there saying something about the respective EVEX
>> encodings.
>>>> But that still requires the VEX encodings connected to these three
>>>> features to also become suitably available. While this works fine for
>>>> GFNI, it doesn't for the other two: The 128-bit VEX encodings, which
>>>> surely are available when the 256-bit ones are, would become
>>>> impossible to use. The assembler would pick the (larger) EVEX forms
>>>> instead. There are two ways to solve this that I can see right away:
>>>> 1) AES becomes a dependency of VAES (and PCLMULQDQ one of
>>>> VPCLMULQDQ)
>>>> 2) We put in place extra templates.
>>>> I'm wary of the first option as long as not at least informally
>>>> supported by you (Intel). Hence I went with option 2 for now.
>>>>
>>>> I'm only done with the /512 patch, so I won't post right away. I'm
>>>> still debating with myself whether to control maximum vector length
>>>> via a new directive, or via a special form of .arch.
>>>
>>> Do you think a command line option like -mavx10maxvl=256/512 with
>>> default 512 is ok for this scenario? I am working to revise the AVX10.1 patch
>> like that.
>>
>> That's certainly an option, but right now I have different plans.
> 
> Actually all the three options are ok for me, they should not be that complex
> based on the current part of v3 patch setting/clearing AVX512 bit for AVX10.1.

Mind me asking what "all the three options" you're referring to here?

Jan
  

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, August 23, 2023 2:24 PM
> To: Jiang, Haochen <haochen.jiang@intel.com>
> Cc: hjl.tools@gmail.com; binutils@sourceware.org
> Subject: Re: [PATCH v2] Support Intel AVX10.1
> 
> On 23.08.2023 08:21, Jiang, Haochen wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Wednesday, August 23, 2023 1:54 PM
> >> To: Jiang, Haochen <haochen.jiang@intel.com>
> >> Cc: hjl.tools@gmail.com; binutils@sourceware.org
> >> Subject: Re: [PATCH v2] Support Intel AVX10.1
> >>
> >> On 23.08.2023 04:20, Jiang, Haochen wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <jbeulich@suse.com>
> >>>> Sent: Friday, August 18, 2023 9:03 PM
> >>>> To: Jiang, Haochen <haochen.jiang@intel.com>
> >>>> Cc: hjl.tools@gmail.com; binutils@sourceware.org
> >>>> Subject: Re: [PATCH v2] Support Intel AVX10.1
> >>>>
> >>>> On 14.08.2023 08:45, Haochen Jiang wrote:
> >>>>> @@ -1315,6 +1321,20 @@ output_i386_opcode (FILE *table, const
> char
> >>>> *name, char *str,
> >>>>>    ident = mkident (name);
> >>>>>    fprintf (table, "  { MN_%s, 0x%0*llx%s, %u,",
> >>>>>  	   ident, 2 * (int)length, opcode, end, i);
> >>>>> +
> >>>>> +  j = strlen(ident);
> >>>>> +  /* All AVX512F based instructions are usable for AVX10.1 except
> >>>>> +     AVX512PF/ER/4FMAPS/4VNNIW/VP2INTERSECT.  */  if (strstr
> >>>>> + (cpu_flags, "AVX512")
> >>>>> +      && !strstr (cpu_flags, "AVX512PF")
> >>>>> +      && !strstr (cpu_flags, "AVX512ER")
> >>>>> +      && !strstr (cpu_flags, "4FMAPS")
> >>>>> +      && !strstr (cpu_flags, "4VNNIW")
> >>>>> +      && !strstr (cpu_flags, "VP2INTERSECT"))
> >>>>> +    {
> >>>>> +      cpu_flags = concat (cpu_flags, "|AVX10_1", NULL);
> >>>>> +      k = 1;
> >>>>> +    }
> >>>>>    free (ident);
> >>>>
> >>>> While making a patch myself along the lines of what I had outlined,
> >>>> I came to realize that the above isn't enough. (I'm pretty sure I
> >>>> wouldn't have spotted this by merely reviewing your patch.) This
> >>>> may be a result of the spec being somewhat ambiguous when it comes
> >>>> to GFNI,
> >> VAES, and VPCLMULQDQ.
> >>>> There's a note there saying something about the respective EVEX
> >> encodings.
> >>>> But that still requires the VEX encodings connected to these three
> >>>> features to also become suitably available. While this works fine
> >>>> for GFNI, it doesn't for the other two: The 128-bit VEX encodings,
> >>>> which surely are available when the 256-bit ones are, would become
> >>>> impossible to use. The assembler would pick the (larger) EVEX forms
> >>>> instead. There are two ways to solve this that I can see right away:
> >>>> 1) AES becomes a dependency of VAES (and PCLMULQDQ one of
> >>>> VPCLMULQDQ)
> >>>> 2) We put in place extra templates.
> >>>> I'm wary of the first option as long as not at least informally
> >>>> supported by you (Intel). Hence I went with option 2 for now.
> >>>>
> >>>> I'm only done with the /512 patch, so I won't post right away. I'm
> >>>> still debating with myself whether to control maximum vector length
> >>>> via a new directive, or via a special form of .arch.
> >>>
> >>> Do you think a command line option like -mavx10maxvl=256/512 with
> >>> default 512 is ok for this scenario? I am working to revise the
> >>> AVX10.1 patch
> >> like that.
> >>
> >> That's certainly an option, but right now I have different plans.
> >
> > Actually all the three options are ok for me, they should not be that
> > complex based on the current part of v3 patch setting/clearing AVX512 bit
> for AVX10.1.
> 
> Mind me asking what "all the three options" you're referring to here?

A new directive, a special form of .arch or the command line option.

Thx,
Haochen

> 
> Jan
  

On 23.08.2023 08:25, Jiang, Haochen wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Wednesday, August 23, 2023 2:24 PM
>> To: Jiang, Haochen <haochen.jiang@intel.com>
>> Cc: hjl.tools@gmail.com; binutils@sourceware.org
>> Subject: Re: [PATCH v2] Support Intel AVX10.1
>>
>> On 23.08.2023 08:21, Jiang, Haochen wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Wednesday, August 23, 2023 1:54 PM
>>>> To: Jiang, Haochen <haochen.jiang@intel.com>
>>>> Cc: hjl.tools@gmail.com; binutils@sourceware.org
>>>> Subject: Re: [PATCH v2] Support Intel AVX10.1
>>>>
>>>> On 23.08.2023 04:20, Jiang, Haochen wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>> Sent: Friday, August 18, 2023 9:03 PM
>>>>>> To: Jiang, Haochen <haochen.jiang@intel.com>
>>>>>> Cc: hjl.tools@gmail.com; binutils@sourceware.org
>>>>>> Subject: Re: [PATCH v2] Support Intel AVX10.1
>>>>>>
>>>>>> On 14.08.2023 08:45, Haochen Jiang wrote:
>>>>>>> @@ -1315,6 +1321,20 @@ output_i386_opcode (FILE *table, const
>> char
>>>>>> *name, char *str,
>>>>>>>    ident = mkident (name);
>>>>>>>    fprintf (table, "  { MN_%s, 0x%0*llx%s, %u,",
>>>>>>>  	   ident, 2 * (int)length, opcode, end, i);
>>>>>>> +
>>>>>>> +  j = strlen(ident);
>>>>>>> +  /* All AVX512F based instructions are usable for AVX10.1 except
>>>>>>> +     AVX512PF/ER/4FMAPS/4VNNIW/VP2INTERSECT.  */  if (strstr
>>>>>>> + (cpu_flags, "AVX512")
>>>>>>> +      && !strstr (cpu_flags, "AVX512PF")
>>>>>>> +      && !strstr (cpu_flags, "AVX512ER")
>>>>>>> +      && !strstr (cpu_flags, "4FMAPS")
>>>>>>> +      && !strstr (cpu_flags, "4VNNIW")
>>>>>>> +      && !strstr (cpu_flags, "VP2INTERSECT"))
>>>>>>> +    {
>>>>>>> +      cpu_flags = concat (cpu_flags, "|AVX10_1", NULL);
>>>>>>> +      k = 1;
>>>>>>> +    }
>>>>>>>    free (ident);
>>>>>>
>>>>>> While making a patch myself along the lines of what I had outlined,
>>>>>> I came to realize that the above isn't enough. (I'm pretty sure I
>>>>>> wouldn't have spotted this by merely reviewing your patch.) This
>>>>>> may be a result of the spec being somewhat ambiguous when it comes
>>>>>> to GFNI,
>>>> VAES, and VPCLMULQDQ.
>>>>>> There's a note there saying something about the respective EVEX
>>>> encodings.
>>>>>> But that still requires the VEX encodings connected to these three
>>>>>> features to also become suitably available. While this works fine
>>>>>> for GFNI, it doesn't for the other two: The 128-bit VEX encodings,
>>>>>> which surely are available when the 256-bit ones are, would become
>>>>>> impossible to use. The assembler would pick the (larger) EVEX forms
>>>>>> instead. There are two ways to solve this that I can see right away:
>>>>>> 1) AES becomes a dependency of VAES (and PCLMULQDQ one of
>>>>>> VPCLMULQDQ)
>>>>>> 2) We put in place extra templates.
>>>>>> I'm wary of the first option as long as not at least informally
>>>>>> supported by you (Intel). Hence I went with option 2 for now.
>>>>>>
>>>>>> I'm only done with the /512 patch, so I won't post right away. I'm
>>>>>> still debating with myself whether to control maximum vector length
>>>>>> via a new directive, or via a special form of .arch.
>>>>>
>>>>> Do you think a command line option like -mavx10maxvl=256/512 with
>>>>> default 512 is ok for this scenario? I am working to revise the
>>>>> AVX10.1 patch
>>>> like that.
>>>>
>>>> That's certainly an option, but right now I have different plans.
>>>
>>> Actually all the three options are ok for me, they should not be that
>>> complex based on the current part of v3 patch setting/clearing AVX512 bit
>> for AVX10.1.
>>
>> Mind me asking what "all the three options" you're referring to here?
> 
> A new directive, a special form of .arch or the command line option.

Oh, I see. Whatever we choose, it'll need to come in both command line
and directive form, I think. And then both want to be sufficiently
similar. As mentioned, I have a firm plan now, but of course I need to
see whether it ends up looking sensibly once actually carried out.

Jan