[2/6] Support Intel AMX-AVX512

  This patch will support AMX-AVX512. In disassmbler, we need to manually
change the operand3 names to r32 when it is register or it will print
out zmm instead.

gas/ChangeLog:

	* NEWS: Support Intel AMX-AVX512.
	* config/tc-i386.c: Add amx_avx512.
	* doc/c-i386.texi: Document .amx_avx512.
	* testsuite/gas/i386/i386.exp: Run AMX-AVX512 tests.
	* testsuite/gas/i386/x86-64.exp: Ditto.
	* testsuite/gas/i386/amx-avx512-inval.l: New test.
	* testsuite/gas/i386/amx-avx512-inval.s: Ditto.
	* testsuite/gas/i386/x86-64-amx-avx512-intel.d: Ditto.
	* testsuite/gas/i386/x86-64-amx-avx512.d: Ditto.
	* testsuite/gas/i386/x86-64-amx-avx512.s: Ditto.

opcodes/ChangeLog:

	* i386-dis-evex-len.h: Add EVEX_LEN_0F384A_X86_64_W_0,
	EVEX_LEN_0F386D_X86_64_W_0, EVEX_LEN_0F3A07_X86_64_W_0,
	EVEX_LEN_0F3A77_X86_64_W_0.
	* i386-dis-evex-prefix.h: Add PREFIX_EVEX_0F384A_W_0_L_2,
	PREFIX_EVEX_0F386D_W_0_L_2, PREFIX_EVEX_0F3A07_W_0_L_2,
	PREFIX_EVEX_0F3A77_W_0_L_2.
	* i386-dis-evex-w.h: Add EVEX_W_0F384A_X86_64, EVEX_W_0F386D_X86_64,
	EVEX_W_0F3A07_X86_64, EVEX_W_0F3A77_X86_64.
	* i386-dis-evex-x86-64.h: Add X86_64_EVEX_0F384A, X86_64_EVEX_0F386D,
	X86_64_EVEX_0F3A07, X86_64_EVEX_0F3A77.
	* i386-dis-evex.h: Ditto.
	* i386-dis.c (EVEX_LEN_0F384A_X86_64_W_0): New.
	(EVEX_LEN_0F386D_X86_64_W_0): Ditto.
	(EVEX_LEN_0F3A07_X86_64_W_0): Ditto.
	(EVEX_LEN_0F3A77_X86_64_W_0): Ditto.
	(MOD_EVEX_0F384A_X86_64_W_0): Ditto.
	(MOD_EVEX_0F386D_X86_64_W_0): Ditto.
	(MOD_EVEX_0F3A07_X86_64_W_0): Ditto.
	(MOD_EVEX_0F3A77_X86_64_W_0): Ditto.
	(PREFIX_EVEX_0F384A_W_0_L_2): Ditto.
	(PREFIX_EVEX_0F386D_W_0_L_2): Ditto.
	(PREFIX_EVEX_0F3A07_W_0_L_2): Ditto.
	(PREFIX_EVEX_0F3A77_W_0_L_2): Ditto.
	(EVEX_W_0F384A_X86_64): Ditto.
	(EVEX_W_0F386D_X86_64): Ditto.
	(EVEX_W_0F3A07_X86_64): Ditto.
	(EVEX_W_0F3A77_X86_64): Ditto.
	(X86_64_EVEX_0F384A): Ditto.
	(X86_64_EVEX_0F386D): Ditto.
	(X86_64_EVEX_0F3A07): Ditto.
	(X86_64_EVEX_0F3A77): Ditto.
	(OP_VEX): Add handler for dq_mode under EVEX512.
	* i386-gen.c (cpu_flag_init): Add CPU_AMX_AVX512_FLAGS and
	CPU_ANY_AMX_AVX512_FLAGS.
	* i386-init.h: Regenerated.
	* i386-mnem.h: Ditto.
	* i386-opc.h (CpuAMX_AVX512): New.
	(i386_cpu_flags): Add cpuamx_avx512.
	* i386-opc.tbl: Add AMX-AVX512 instructions.
	* i386-tbl.h: Regenerated.
---
 gas/NEWS                                      |    2 +
 gas/config/tc-i386.c                          |    1 +
 gas/doc/c-i386.texi                           |    4 +-
 gas/testsuite/gas/i386/amx-avx512-inval.l     |    7 +
 gas/testsuite/gas/i386/amx-avx512-inval.s     |   11 +
 gas/testsuite/gas/i386/i386.exp               |    1 +
 .../gas/i386/x86-64-amx-avx512-intel.d        |   35 +
 gas/testsuite/gas/i386/x86-64-amx-avx512.d    |   34 +
 gas/testsuite/gas/i386/x86-64-amx-avx512.s    |   55 +
 gas/testsuite/gas/i386/x86-64.exp             |    2 +
 opcodes/i386-dis-evex-len.h                   |   28 +
 opcodes/i386-dis-evex-prefix.h                |   27 +
 opcodes/i386-dis-evex-w.h                     |   16 +
 opcodes/i386-dis-evex-x86-64.h                |   20 +
 opcodes/i386-dis-evex.h                       |    8 +-
 opcodes/i386-dis.c                            |   22 +-
 opcodes/i386-gen.c                            |    3 +
 opcodes/i386-init.h                           |  766 ++---
 opcodes/i386-mnem.h                           | 2554 +++++++++--------
 opcodes/i386-opc.h                            |    3 +
 opcodes/i386-opc.tbl                          |   15 +
 opcodes/i386-tbl.h                            |  416 ++-
 22 files changed, 2244 insertions(+), 1786 deletions(-)
 create mode 100644 gas/testsuite/gas/i386/amx-avx512-inval.l
 create mode 100644 gas/testsuite/gas/i386/amx-avx512-inval.s
 create mode 100644 gas/testsuite/gas/i386/x86-64-amx-avx512-intel.d
 create mode 100644 gas/testsuite/gas/i386/x86-64-amx-avx512.d
 create mode 100644 gas/testsuite/gas/i386/x86-64-amx-avx512.s
  

On 13.11.2024 09:44, Haochen Jiang wrote:
> This patch will support AMX-AVX512. In disassmbler, we need to manually
> change the operand3 names to r32 when it is register or it will print
> out zmm instead.

Just to mention it in public as well, if only for posterity: The spec
looks suspicious in a number of aspects. Until its correctness was
confirmed, or it was corrected, there's no basis for approving these
changes. Last thing we want is change encodings perhaps even after one
form had been part of a release.

This also affects other parts of this series, ftaod.

Jan
  

On 13.11.2024 09:44, Haochen Jiang wrote:
> --- a/gas/NEWS
> +++ b/gas/NEWS
> @@ -1,5 +1,7 @@
>  -*- text -*-
>  
> +* Add support for Intel AMX-AVX512 instructions.
> +
>  * Add support for Intel AMX-TRANSPOSE instructions.

As they're closely related, I think all AMX-* together want to take just a
single list entry.

> --- a/gas/testsuite/gas/i386/i386.exp
> +++ b/gas/testsuite/gas/i386/i386.exp
> @@ -547,6 +547,7 @@ if [gas_32_check] then {
>      run_dump_test "avx10_2-256-miscs-intel"
>      run_list_test "msr_imm-inval"
>      run_list_test "amx-transpose-inval"
> +    run_list_test "amx-avx512-inval"

See comment on earlier patch.

> --- a/opcodes/i386-dis.c
> +++ b/opcodes/i386-dis.c
> @@ -592,6 +592,7 @@ fetch_error (const instr_info *ins)
>  #define VexGatherD { OP_VEX, vex_vsib_d_w_dq_mode }
>  #define VexGatherQ { OP_VEX, vex_vsib_q_w_dq_mode }
>  #define VexGdq { OP_VEX, dq_mode }
> +#define VexGd { OP_VEX, d_mode }

Why wouldn't VexGdq be suitable to use?

> @@ -13931,6 +13949,8 @@ OP_VEX (instr_info *ins, int bytemode, int sizeflag ATTRIBUTE_UNUSED)
>      case 512:
>        names = att_names_zmm;
>        ins->evex_used |= EVEX_len_used;
> +      if (bytemode == d_mode)
> +	names = att_names32;
>        break;
>      default:
>        abort ();

Irrespective of VexGd (i.e. d_mode) or VexGdq (dq_mode) - the GPR handling
imo simply wants pulling out of this switch().

> --- a/opcodes/i386-gen.c
> +++ b/opcodes/i386-gen.c
> @@ -265,6 +265,8 @@ static const dependency isa_dependencies[] =
>      "AMX_TILE" },
>    { "AMX_TRANSPOSE",
>      "AMX_TILE" },
> +  { "AMX_AVX512",
> +    "AMX_TILE|AVX10_2" },

This dependency looks certainly correct to add, yet how does that fit with
all insns only supporting VL=512, when AVX10 is specifically about permitting
vector lengths only up to 256 in hardware?

> --- a/opcodes/i386-opc.tbl
> +++ b/opcodes/i386-opc.tbl
> @@ -3204,6 +3204,19 @@ tconjtcmmimfp16ps, 0x6b, AMX_COMPLEX&AMX_TRANSPOSE, Modrm|Vex128|Space0F38|Src2V
>  
>  tconjtfp16, 0x666b, AMX_COMPLEX&AMX_TRANSPOSE, Modrm|Vex128|Space0F38|VexW0|NoSuf, { RegTMM, RegTMM }
>  
> +tcvtrowd2ps, 0xf34a, AMX_AVX512, Modrm|EVex512|Space0F38|Src2VVVV|VexW0|NoSuf, { Reg32, RegTMM, RegZMM }
> +tcvtrowd2ps, 0xf307, AMX_AVX512, Modrm|EVex512|Space0F3A|VexW0|NoSuf, { Imm8, RegTMM, RegZMM }
> +
> +tcvtrowps2pbf16h, 0xf26d, AMX_AVX512, Modrm|EVex512|Space0F38|Src2VVVV|VexW0|NoSuf, { Reg32, RegTMM, RegZMM }
> +tcvtrowps2pbf16h, 0xf207, AMX_AVX512, Modrm|EVex512|Space0F3A|VexW0|NoSuf, { Imm8, RegTMM, RegZMM }
> +tcvtrowps2pbf16l, 0xf36d, AMX_AVX512, Modrm|EVex512|Space0F38|Src2VVVV|VexW0|NoSuf, { Reg32, RegTMM, RegZMM }
> +tcvtrowps2pbf16l, 0xf377, AMX_AVX512, Modrm|EVex512|Space0F3A|VexW0|NoSuf, { Imm8, RegTMM, RegZMM }
> +
> +tcvtrowps2phh, 0x6d, AMX_AVX512, Modrm|EVex512|Space0F38|Src2VVVV|VexW0|NoSuf, { Reg32, RegTMM, RegZMM }
> +tcvtrowps2phh, 0x07, AMX_AVX512, Modrm|EVex512|Space0F3A|VexW0|NoSuf, { Imm8, RegTMM, RegZMM }
> +tcvtrowps2phl, 0x666d, AMX_AVX512, Modrm|EVex512|Space0F38|Src2VVVV|VexW0|NoSuf, { Reg32, RegTMM, RegZMM }
> +tcvtrowps2phl, 0xf277, AMX_AVX512, Modrm|EVex512|Space0F3A|VexW0|NoSuf, { Imm8, RegTMM, RegZMM }
> +
>  tdpbf16ps, 0xf35c, AMX_BF16, Modrm|Vex128|Space0F38|Src2VVVV|VexW0|NoSuf, { RegTMM, RegTMM, RegTMM }
>  tdpfp16ps, 0xf25c, AMX_FP16, Modrm|Vex128|Space0F38|Src2VVVV|VexW0|NoSuf, { RegTMM, RegTMM, RegTMM }
>  tdpbssd, 0xf25e, AMX_INT8, Modrm|Vex128|Space0F38|Src2VVVV|VexW0|NoSuf, { RegTMM, RegTMM, RegTMM }
> @@ -3213,6 +3226,8 @@ tdpbsud, 0xf35e, AMX_INT8, Modrm|Vex128|Space0F38|Src2VVVV|VexW0|NoSuf, { RegTMM
>  
>  tileloadd, 0xf24b, APX_F(AMX_TILE), Sibmem|Vex128|EVex128|Space0F38|VexW0|NoSuf, { Unspecified|BaseIndex, RegTMM }
>  tileloaddt1, 0x664b, APX_F(AMX_TILE), Sibmem|Vex128|EVex128|Space0F38|VexW0|NoSuf, { Unspecified|BaseIndex, RegTMM }
> +tilemovrow, 0x664a, AMX_AVX512, Modrm|EVex512|Space0F38|Src2VVVV|VexW0|NoSuf, { Reg32, RegTMM, RegZMM }
> +tilemovrow, 0x6607, AMX_AVX512, Modrm|EVex512|Space0F3A|VexW0|NoSuf, { Imm8, RegTMM, RegZMM }
>  tilestored, 0xf34b, APX_F(AMX_TILE), Sibmem|Vex128|EVex128|Space0F38|VexW0|NoSuf, { RegTMM, Unspecified|BaseIndex }
>  
>  tilerelease, 0x49c0, AMX_TILE, Vex128|Space0F38|VexW0|NoSuf, {}

Again I'm wondering why the additions are scattered around, rather than kept
together (and not going in the middle of other sub-groups). Hmm, now that I
look at this a 3rd time - is this perhaps an attempt to sort alphabetically?
Such sorting is imo fine as a secondary criteria; the first imo ought to be
the feature.

And just to mention it here again - this shouldn't go in without the encoding
anomalies sorted, one way or the other.

Jan
  

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, November 15, 2024 10:04 PM
> 
> > --- a/opcodes/i386-dis.c
> > +++ b/opcodes/i386-dis.c
> > @@ -592,6 +592,7 @@ fetch_error (const instr_info *ins)  #define
> > VexGatherD { OP_VEX, vex_vsib_d_w_dq_mode }  #define VexGatherQ {
> > OP_VEX, vex_vsib_q_w_dq_mode }  #define VexGdq { OP_VEX, dq_mode }
> > +#define VexGd { OP_VEX, d_mode }
> 
> Why wouldn't VexGdq be suitable to use?

VexGdq could be used but not that exact on meaning. I actually used VexGdq
at the very beginning but eventually used d_mode due to only r32 is permitted
for clearness. I am ok to go either way.

> 
> > @@ -13931,6 +13949,8 @@ OP_VEX (instr_info *ins, int bytemode, int
> sizeflag ATTRIBUTE_UNUSED)
> >      case 512:
> >        names = att_names_zmm;
> >        ins->evex_used |= EVEX_len_used;
> > +      if (bytemode == d_mode)
> > +	names = att_names32;
> >        break;
> >      default:
> >        abort ();
> 
> Irrespective of VexGd (i.e. d_mode) or VexGdq (dq_mode) - the GPR handling
> imo simply wants pulling out of this switch().

Let me find a way to get it out. It falls to here actually due to VexGd/VexGdq.

> 
> > --- a/opcodes/i386-gen.c
> > +++ b/opcodes/i386-gen.c
> > @@ -265,6 +265,8 @@ static const dependency isa_dependencies[] =
> >      "AMX_TILE" },
> >    { "AMX_TRANSPOSE",
> >      "AMX_TILE" },
> > +  { "AMX_AVX512",
> > +    "AMX_TILE|AVX10_2" },
> 
> This dependency looks certainly correct to add, yet how does that fit with all
> insns only supporting VL=512, when AVX10 is specifically about permitting
> vector lengths only up to 256 in hardware?
>

I did not quite get the question. I guess your concern is whether it will be an
insn only support VL=128/256 for AVX10. I suppose there won't be that or it
will be quite disastrous.

> 
> And just to mention it here again - this shouldn't go in without the encoding
> anomalies sorted, one way or the other.

Yes, let's wait for that.

Thx,
Haochen
  

On 19.11.2024 04:15, Jiang, Haochen wrote:
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, November 15, 2024 10:04 PM
>>
>>> --- a/opcodes/i386-dis.c
>>> +++ b/opcodes/i386-dis.c
>>> @@ -592,6 +592,7 @@ fetch_error (const instr_info *ins)  #define
>>> VexGatherD { OP_VEX, vex_vsib_d_w_dq_mode }  #define VexGatherQ {
>>> OP_VEX, vex_vsib_q_w_dq_mode }  #define VexGdq { OP_VEX, dq_mode }
>>> +#define VexGd { OP_VEX, d_mode }
>>
>> Why wouldn't VexGdq be suitable to use?
> 
> VexGdq could be used but not that exact on meaning. I actually used VexGdq
> at the very beginning but eventually used d_mode due to only r32 is permitted
> for clearness. I am ok to go either way.

My take here is: Re-use what's available whenever possible, in preference
to adding something new.

>>> @@ -13931,6 +13949,8 @@ OP_VEX (instr_info *ins, int bytemode, int
>> sizeflag ATTRIBUTE_UNUSED)
>>>      case 512:
>>>        names = att_names_zmm;
>>>        ins->evex_used |= EVEX_len_used;
>>> +      if (bytemode == d_mode)
>>> +	names = att_names32;
>>>        break;
>>>      default:
>>>        abort ();
>>
>> Irrespective of VexGd (i.e. d_mode) or VexGdq (dq_mode) - the GPR handling
>> imo simply wants pulling out of this switch().
> 
> Let me find a way to get it out. It falls to here actually due to VexGd/VexGdq.

Right, so taking care of the case e.g. ahead of the switch() would likely
cover both original and new use cases.

>>> --- a/opcodes/i386-gen.c
>>> +++ b/opcodes/i386-gen.c
>>> @@ -265,6 +265,8 @@ static const dependency isa_dependencies[] =
>>>      "AMX_TILE" },
>>>    { "AMX_TRANSPOSE",
>>>      "AMX_TILE" },
>>> +  { "AMX_AVX512",
>>> +    "AMX_TILE|AVX10_2" },
>>
>> This dependency looks certainly correct to add, yet how does that fit with all
>> insns only supporting VL=512, when AVX10 is specifically about permitting
>> vector lengths only up to 256 in hardware?
>>
> 
> I did not quite get the question. I guess your concern is whether it will be an
> insn only support VL=128/256 for AVX10. I suppose there won't be that or it
> will be quite disastrous.

It's a spec question: Why are 256 (and 128) bit forms not specified right
away? There's hardly any other insn in AVX10.2 that becomes unavailable
entirely when vsz512 is clear in the CPUID leaf. And those few insns then
disappear truly for a reason. Whereas the ones here "naturally" extend to
VL=256 and VL=128, given how their operation is described.

Jan
  

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Tuesday, November 19, 2024 4:57 PM
> 
> On 19.11.2024 04:15, Jiang, Haochen wrote:
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Friday, November 15, 2024 10:04 PM
> >>> --- a/opcodes/i386-gen.c
> >>> +++ b/opcodes/i386-gen.c
> >>> @@ -265,6 +265,8 @@ static const dependency isa_dependencies[] =
> >>>      "AMX_TILE" },
> >>>    { "AMX_TRANSPOSE",
> >>>      "AMX_TILE" },
> >>> +  { "AMX_AVX512",
> >>> +    "AMX_TILE|AVX10_2" },
> >>
> >> This dependency looks certainly correct to add, yet how does that fit with
> all
> >> insns only supporting VL=512, when AVX10 is specifically about permitting
> >> vector lengths only up to 256 in hardware?
> >>
> >
> > I did not quite get the question. I guess your concern is whether it will be an
> > insn only support VL=128/256 for AVX10. I suppose there won't be that or it
> > will be quite disastrous.
> 
> It's a spec question: Why are 256 (and 128) bit forms not specified right
> away? There's hardly any other insn in AVX10.2 that becomes unavailable
> entirely when vsz512 is clear in the CPUID leaf. And those few insns then
> disappear truly for a reason. Whereas the ones here "naturally" extend to
> VL=256 and VL=128, given how their operation is described.

Per my understanding, there needn't be VL=128/256 form here. A row in tmm is
always 16 elements. With each element FP32, it will always be 512 bit.

Thx,
Haochen
  

On 21.11.2024 07:01, Jiang, Haochen wrote:
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Tuesday, November 19, 2024 4:57 PM
>>
>> On 19.11.2024 04:15, Jiang, Haochen wrote:
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Friday, November 15, 2024 10:04 PM
>>>>> --- a/opcodes/i386-gen.c
>>>>> +++ b/opcodes/i386-gen.c
>>>>> @@ -265,6 +265,8 @@ static const dependency isa_dependencies[] =
>>>>>      "AMX_TILE" },
>>>>>    { "AMX_TRANSPOSE",
>>>>>      "AMX_TILE" },
>>>>> +  { "AMX_AVX512",
>>>>> +    "AMX_TILE|AVX10_2" },
>>>>
>>>> This dependency looks certainly correct to add, yet how does that fit with
>> all
>>>> insns only supporting VL=512, when AVX10 is specifically about permitting
>>>> vector lengths only up to 256 in hardware?
>>>>
>>>
>>> I did not quite get the question. I guess your concern is whether it will be an
>>> insn only support VL=128/256 for AVX10. I suppose there won't be that or it
>>> will be quite disastrous.
>>
>> It's a spec question: Why are 256 (and 128) bit forms not specified right
>> away? There's hardly any other insn in AVX10.2 that becomes unavailable
>> entirely when vsz512 is clear in the CPUID leaf. And those few insns then
>> disappear truly for a reason. Whereas the ones here "naturally" extend to
>> VL=256 and VL=128, given how their operation is described.
> 
> Per my understanding, there needn't be VL=128/256 form here. A row in tmm is
> always 16 elements. With each element FP32, it will always be 512 bit.

That's not my understanding. For one the insns may move only part of a row
(controlled by the top two bits of the immediate). Plus the size of a row
also depends on tile configuration. See the "Operation" section of the insns.

Jan
  

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Thursday, November 21, 2024 6:14 PM
> 
> On 21.11.2024 07:01, Jiang, Haochen wrote:
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Tuesday, November 19, 2024 4:57 PM
> >>
> >> It's a spec question: Why are 256 (and 128) bit forms not specified
> >> right away? There's hardly any other insn in AVX10.2 that becomes
> >> unavailable entirely when vsz512 is clear in the CPUID leaf. And
> >> those few insns then disappear truly for a reason. Whereas the ones
> >> here "naturally" extend to
> >> VL=256 and VL=128, given how their operation is described.
> >
> > Per my understanding, there needn't be VL=128/256 form here. A row in
> > tmm is always 16 elements. With each element FP32, it will always be 512 bit.
> 
> That's not my understanding. For one the insns may move only part of a row
> (controlled by the top two bits of the immediate). Plus the size of a row also
> depends on tile configuration. See the "Operation" section of the insns.

The problem is how could you get the row size and immediate value before you
determine the register size. Or it will over-complex the logic for determining
whether the inst is valid or not. Row size is in config and immediate value needs
extra interpretation. One of two configured wrongly will cause VL=128/256
get an overflow. Zmm is the only safe choice here. 

Even if the element does not hit maximum of 16 rows here, the remaining
will be kept as zero and as placeholder. So it is safe to move them all to zmm.

Thx,
Haochen
  

On 22.11.2024 03:43, Jiang, Haochen wrote:
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Thursday, November 21, 2024 6:14 PM
>>
>> On 21.11.2024 07:01, Jiang, Haochen wrote:
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Tuesday, November 19, 2024 4:57 PM
>>>>
>>>> It's a spec question: Why are 256 (and 128) bit forms not specified
>>>> right away? There's hardly any other insn in AVX10.2 that becomes
>>>> unavailable entirely when vsz512 is clear in the CPUID leaf. And
>>>> those few insns then disappear truly for a reason. Whereas the ones
>>>> here "naturally" extend to
>>>> VL=256 and VL=128, given how their operation is described.
>>>
>>> Per my understanding, there needn't be VL=128/256 form here. A row in
>>> tmm is always 16 elements. With each element FP32, it will always be 512 bit.
>>
>> That's not my understanding. For one the insns may move only part of a row
>> (controlled by the top two bits of the immediate). Plus the size of a row also
>> depends on tile configuration. See the "Operation" section of the insns.
> 
> The problem is how could you get the row size and immediate value before you
> determine the register size. Or it will over-complex the logic for determining
> whether the inst is valid or not. Row size is in config and immediate value needs
> extra interpretation.

All of this is, at least very likely, known to the person writing the code.

> One of two configured wrongly will cause VL=128/256
> get an overflow. Zmm is the only safe choice here. 

And the insn then entirely unavailable on AVX10.2/256.

Jan
  

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, November 22, 2024 5:29 PM
> 
> On 22.11.2024 03:43, Jiang, Haochen wrote:
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Thursday, November 21, 2024 6:14 PM
> >>
> >> On 21.11.2024 07:01, Jiang, Haochen wrote:
> >>>> From: Jan Beulich <jbeulich@suse.com>
> >>>> Sent: Tuesday, November 19, 2024 4:57 PM
> >>>>
> >>>> It's a spec question: Why are 256 (and 128) bit forms not specified
> >>>> right away? There's hardly any other insn in AVX10.2 that becomes
> >>>> unavailable entirely when vsz512 is clear in the CPUID leaf. And
> >>>> those few insns then disappear truly for a reason. Whereas the ones
> >>>> here "naturally" extend to
> >>>> VL=256 and VL=128, given how their operation is described.
> >>>
> >>> Per my understanding, there needn't be VL=128/256 form here. A row
> >>> in tmm is always 16 elements. With each element FP32, it will always be
> 512 bit.
> >>
> >> That's not my understanding. For one the insns may move only part of
> >> a row (controlled by the top two bits of the immediate). Plus the
> >> size of a row also depends on tile configuration. See the "Operation"
> section of the insns.
> >
> > The problem is how could you get the row size and immediate value
> > before you determine the register size. Or it will over-complex the
> > logic for determining whether the inst is valid or not. Row size is in
> > config and immediate value needs extra interpretation.
> 
> All of this is, at least very likely, known to the person writing the code.
> 
> > One of two configured wrongly will cause VL=128/256 get an overflow.
> > Zmm is the only safe choice here.
> 
> And the insn then entirely unavailable on AVX10.2/256.
> 

That is true. It is not available under AVX10.2/256 only since it will always need
to use zmm. We need AVX10.2/512 enabled.

Thx,
Haochen
  

On 25.11.2024 04:00, Jiang, Haochen wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, November 22, 2024 5:29 PM
>>
>> On 22.11.2024 03:43, Jiang, Haochen wrote:
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Thursday, November 21, 2024 6:14 PM
>>>>
>>>> On 21.11.2024 07:01, Jiang, Haochen wrote:
>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>> Sent: Tuesday, November 19, 2024 4:57 PM
>>>>>>
>>>>>> It's a spec question: Why are 256 (and 128) bit forms not specified
>>>>>> right away? There's hardly any other insn in AVX10.2 that becomes
>>>>>> unavailable entirely when vsz512 is clear in the CPUID leaf. And
>>>>>> those few insns then disappear truly for a reason. Whereas the ones
>>>>>> here "naturally" extend to
>>>>>> VL=256 and VL=128, given how their operation is described.
>>>>>
>>>>> Per my understanding, there needn't be VL=128/256 form here. A row
>>>>> in tmm is always 16 elements. With each element FP32, it will always be
>> 512 bit.
>>>>
>>>> That's not my understanding. For one the insns may move only part of
>>>> a row (controlled by the top two bits of the immediate). Plus the
>>>> size of a row also depends on tile configuration. See the "Operation"
>> section of the insns.
>>>
>>> The problem is how could you get the row size and immediate value
>>> before you determine the register size. Or it will over-complex the
>>> logic for determining whether the inst is valid or not. Row size is in
>>> config and immediate value needs extra interpretation.
>>
>> All of this is, at least very likely, known to the person writing the code.
>>
>>> One of two configured wrongly will cause VL=128/256 get an overflow.
>>> Zmm is the only safe choice here.
>>
>> And the insn then entirely unavailable on AVX10.2/256.
>>
> 
> That is true. It is not available under AVX10.2/256 only since it will always need
> to use zmm. We need AVX10.2/512 enabled.

IOW a first stain on the shiny new AVX10, even before hardware is available.
Interesting, especially when it would be straightforward to avoid.

Jan