[PATCH 2/6] Support Intel AMX-AVX512

[Jan Beulich]

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