[PATCH 2/6] Support Intel AMX-AVX512

[Jan Beulich]

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