[PATCH 1/2] [PATCH 1/2] Enable Intel AVX512_FP16 instructions

[Jan Beulich]

On 13.07.2021 08:58, Cui, Lili wrote:

Disassembler:

d_scalar_mode looks to be unused.

This

  /* EVEX_W_MAP5_2A_P_1 */
  {
    { "vcvtsi2sh{%LQ|}",	{ XMScalar, VexScalar, EXxEVexR, Ed }, 0 },
    { "vcvtsi2sh{%LQ|}",	{ XMScalar, VexScalar, EXxEVexR, Eq }, 0 },
  },

can imo be expressed without decoding EVEX.W, by using Edq instead
of (separately) Ed and Eq. There's at least one similar case
elsewhere. Interestingly in the 2si/2usi conversions you do use
Gdq already, which I think handles the EVEX.W=1 case correctly
outside of 64-bit mode (unlike Eq, which will unconditionally
produce 64-bit register names afaict).

As to a broader question on decoding EVEX.W: Did you consider
introducing e.g. %XH (paralleling %XW, just that EVEX.W=1 is not a
valid encoding), to avoid this decode step for perhaps almost all
entries? And if that's not an option, decoding EVEX.W first for
all the opcodes which previously had no meaning at all would, in
some cases, reduce the overall number of table entries (and in all
other cases this would then merely be for consistency, as it also
wouldn't increase the number of table entries). To give an example:

    { PREFIX_TABLE (PREFIX_EVEX_0F3AC2) },

=>

  /* PREFIX_EVEX_0F3AC2 */
  {
    { VEX_W_TABLE (EVEX_W_0F3AC2_P_0) },
    { VEX_W_TABLE (EVEX_W_0F3AC2_P_1) },
  },

=>

  /* EVEX_W_0F3AC2_P_0 */
  {
    { "vcmpph",	{ XMask, Vex, EXxh, EXxEVexS, Ib }, 0 },
  },
  /* EVEX_W_0F3AC2_P_1 */
  {
    { "vcmpsh",	{ XMask, VexScalar, EXxmm_mw, EXxEVexS, Ib }, 0 },
  },

i.e. a total of 1 + 4 + 2 * 2 entries. Whereas decoding W first
would yield 1 (evex) + 2 (evex_w) + 4 (prefix) entries. The
delta is even larger for something like MAP5_7D: 1 + 4 + 4 * 2
vs. 1 + 2 + 4. This also results in more related entries ending
up closer to one another.

As to formatting, it looks as if the first hunk changing
intel_operand_size() mis-indents the return statement that was
there already before.

Jan