[PATCH 2/6] Support Intel AMX-AVX512

[Jan Beulich]

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