[PATCH 2/6] Support Intel AMX-AVX512

[Jiang, Haochen]

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, November 15, 2024 10:04 PM
> 
> > --- a/opcodes/i386-dis.c
> > +++ b/opcodes/i386-dis.c
> > @@ -592,6 +592,7 @@ fetch_error (const instr_info *ins)  #define
> > VexGatherD { OP_VEX, vex_vsib_d_w_dq_mode }  #define VexGatherQ {
> > OP_VEX, vex_vsib_q_w_dq_mode }  #define VexGdq { OP_VEX, dq_mode }
> > +#define VexGd { OP_VEX, d_mode }
> 
> Why wouldn't VexGdq be suitable to use?

VexGdq could be used but not that exact on meaning. I actually used VexGdq
at the very beginning but eventually used d_mode due to only r32 is permitted
for clearness. I am ok to go either way.

> 
> > @@ -13931,6 +13949,8 @@ OP_VEX (instr_info *ins, int bytemode, int
> sizeflag ATTRIBUTE_UNUSED)
> >      case 512:
> >        names = att_names_zmm;
> >        ins->evex_used |= EVEX_len_used;
> > +      if (bytemode == d_mode)
> > +	names = att_names32;
> >        break;
> >      default:
> >        abort ();
> 
> Irrespective of VexGd (i.e. d_mode) or VexGdq (dq_mode) - the GPR handling
> imo simply wants pulling out of this switch().

Let me find a way to get it out. It falls to here actually due to VexGd/VexGdq.

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

> 
> And just to mention it here again - this shouldn't go in without the encoding
> anomalies sorted, one way or the other.

Yes, let's wait for that.

Thx,
Haochen