[PATCH 2/6] Support Intel AMX-AVX512

[Jiang, Haochen]

> 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