[PATCH V2 3/8] Support APX GPR32 with extend evex prefix

[Cui, Lili]

> On 14.11.2023 08:42, Cui, Lili wrote:
> >>
> >>> --- a/opcodes/i386-dis-evex-len.h
> >>> +++ b/opcodes/i386-dis-evex-len.h
> >>> @@ -62,6 +62,16 @@ static const struct dis386 evex_len_table[][3] = {
> >>>      { REG_TABLE (REG_EVEX_0F38C7_L_2) },
> >>>    },
> >>>
> >>> +  /* EVEX_LEN_0F38F2 */
> >>> +  {
> >>> +    { "andnS",		{ Gdq, VexGdq, Edq }, 0 },
> >>> +  },
> >>
> >> There's no sign of a prefix decode step here.
> >>> +  /* MOD_EVEX_MAP4_F9 */
> >>> +  {
> >>> +    { "movdiri",	{ Edq, Gdq }, 0 },
> >>> +  },
> >>
> >
> >> Missing PREFIX_OPCODE?
> >
> > Legacy both have PREFIX_OPCODE, but currently EVEX seems to only use
> the vex.w bit to check the operand size. I'm confused whether we should add
> PREFIX_OPCODE ? Currently it reports bad.
> > case PREFIX_OPCODE:
> > ...
> >          (ins.vex.evex && dp->prefix_requirement != PREFIX_DATA
> >               && !ins.vex.w != !(ins.used_prefixes & PREFIX_DATA))
> 
> Considering the context where this appears, this could equally be written as
> 
>          (ins.vex.evex && dp->prefix_requirement == PREFIX_OPCODE
>               && !ins.vex.w != !(ins.used_prefixes & PREFIX_DATA))
> 
> and is about many vector-FP AVX512 insns needing EVEX.W == EVEX.pp. From
> that angle using PREFIX_OPCODE in the entries above doesn't look to be right;
> I'm sorry for the wrong comment. Yet still EVEX.pp needs dealing with
> everywhere, including for the entries above. Whether that's done by going
> through prefix_table[] or by introducing a new PREFIX_* qualifier or by yet
> other means is secondary (and a question of what's most efficient).
> 

I would let them go through prefix_table[].

Thanks,
Lili.