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

[Jan Beulich]

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

Jan