[PATCH 2/6] Support Intel AMX-AVX512
Jiang, Haochen
haochen.jiang@intel.com
Thu Nov 21 06:01:10 GMT 2024
> 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.
Thx,
Haochen
More information about the Binutils
mailing list