[PATCH v2] Support Intel AMX-AVX512

[Jiang, Haochen]

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Tuesday, January 7, 2025 12:29 AM
> 
> On 03.01.2025 03:50, Haochen Jiang wrote:
> > Hi all,
> >
> It is again nowhere in the patch metadata that you put down what other non-
> upstream patch(es) this one goes on top of. This is important info for a
> reviewer. Since this isn't the first time, let me make it quite
> clear: Going forward I may simply refuse to review (reject) patches with
> unclear dependencies.

Let me clarify why it is sent out this way. The patch is originally in the same
series with previous patches (some are upstreamed, some are not approved for
current status). But due to the encoding issue, it got split out of the series during
the review.

Maybe I should name this explicitly to avoid that inconvenience or send them
within the patch series to make everything better.

> 
> > @@ -14070,6 +14083,29 @@ OP_VEX (instr_info *ins, int bytemode, int
> sizeflag ATTRIBUTE_UNUSED)
> >        return true;
> >      }
> >
> > +  switch (bytemode)
> > +    {
> > +      case v_mode:
> > +      case dq_mode:
> > +	if (ins->rex & REX_W)
> > +	  names = att_names64;
> > +	else if (bytemode == v_mode
> > +		  && !(sizeflag & DFLAG))
> > +	  names = att_names16;
> > +	else
> > +	  names = att_names32;
> > +	oappend_register (ins, names[reg]);
> > +	return true;
> > +      case b_mode:
> > +	names = att_names8rex;
> > +	oappend_register (ins, names[reg]);
> > +	return true;
> > +      case q_mode:
> > +	names = att_names64;
> > +	oappend_register (ins, names[reg]);
> > +	return true;
> > +    }
> 
> I think there are two ways to improve legibility here: Either pull out the call to
> oappend_register() (and the return), or avoid using the "names"
> local var in the latter two cases.

Let me have a try.

> 
> > +tilemovrow, 0x664a, AMX_AVX512,
> > +Modrm|EVex512|Space0F38|Src2VVVV|VexW0|NoSuf, { Reg32,
> RegTMM, RegZMM
> > +} tilemovrow, 0x6607, AMX_AVX512,
> > +Modrm|EVex512|Space0F3A|VexW0|NoSuf, { Imm8, RegTMM,
> RegZMM }
> 
> Just to double check: The AVX10.2/256 case really is of no interest for this
> feature / these insns, and your designers would rather introduce yet another
> CPUID flag in case it turned out desirable later on?

Yes, they have nothing to do with AVX10.2/256.

Thx,
Haochen