[PATCH 2/6] Support Intel AMX-AVX512

[Jiang, Haochen]

> -----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