RE: [PATCH v4 3/9] Support APX GPR32 with extend evex prefix

["Cui, Lili" <lili.cui@intel.com>]

> > --- a/opcodes/i386-dis-evex-prefix.h
> > +++ b/opcodes/i386-dis-evex-prefix.h
> > @@ -285,6 +285,14 @@
> >      { "%XEvfmsub213s%XW",	{ XMScalar, VexScalar, EXdq, EXxEVexR }, 0 },
> >      { "v4fnmadds%XS",	{ XMScalar, VexScalar, Mxmm }, 0 },
> >    },
> > +  /* PREFIX_EVEX_0F38F2_L_0 */
> > +  {
> > +    { "andnS",	{ Gdq, VexGdq, Edq }, 0 },
> > +  },
> 
> So not being able to re-use the VEX entry for this and ...
> 
> > --- a/opcodes/i386-dis-evex-reg.h
> > +++ b/opcodes/i386-dis-evex-reg.h
> > @@ -49,3 +49,10 @@
> >      { "vscatterpf0qp%XW",  { MVexVSIBQWpX }, PREFIX_DATA },
> >      { "vscatterpf1qp%XW",  { MVexVSIBQWpX }, PREFIX_DATA },
> >    },
> > +  /* REG_EVEX_0F38F3_L_0_P_0 */
> > +  {
> > +    { Bad_Opcode },
> > +    { "blsrS",	{ VexGdq, Edq }, 0 },
> > +    { "blsmskS",	{ VexGdq, Edq }, 0 },
> > +    { "blsiS",	{ VexGdq, Edq }, 0 },
> > +  },              
> 
> ... this was due to the VEX entries having PREFIX_OPCODE, which would be
> getting in the way? This is the sort of thing that would be useful to have in the
> description, to avoid raising the same question again that (I think) was raised
> before.
> 
> Yet then - why do you strip PREFIX_OPCODE from the VEX entries? If you do
> that (as iirc I did suggest), there's no need for having separate EVEX ones (the
> suggestion, after all, was to be able to re-use the VEX entries). That re-work of
> existing VEX encodings could, btw, also have been split out quite easily. That
> way this huge patch would have further shrunk a little.
> 
I re-used the VEX entry, but forgot to remove the redundant, removed.

> > --- /dev/null
> > +++ b/opcodes/i386-dis-evex-x86-64.h
> > @@ -0,0 +1,50 @@
> > +  /* X86_64_EVEX_0F90 */
> > +  {
> > +    { Bad_Opcode },
> > +    { VEX_W_TABLE (VEX_W_0F90_L_0) },  },
> > +  /* X86_64_EVEX_0F91 */
> > +  {
> > +    { Bad_Opcode },
> > +    { VEX_W_TABLE (VEX_W_0F91_L_0) },  },
> > +  /* X86_64_EVEX_0F92 */
> > +  {
> > +    { Bad_Opcode },
> > +    { VEX_W_TABLE (VEX_W_0F92_L_0) },  },
> > +  /* X86_64_EVEX_0F93 */
> > +  {
> > +    { Bad_Opcode },
> > +    { VEX_W_TABLE (VEX_W_0F93_L_0) },  },
> > +  /* X86_64_EVEX_0F38F2 */
> > +  {
> > +    { Bad_Opcode },
> > +    { PREFIX_TABLE (PREFIX_VEX_0F38F2_L_0) },  },
> > +  /* X86_64_EVEX_0F38F3 */
> > +  {
> > +    { Bad_Opcode },
> > +    { PREFIX_TABLE (PREFIX_VEX_0F38F3_L_0) },  },
> > +  /* X86_64_EVEX_0F38F5 */
> > +  {
> > +    { Bad_Opcode },
> > +    { PREFIX_TABLE (PREFIX_VEX_0F38F5_L_0) },  },
> > +  /* X86_64_EVEX_0F38F6 */
> > +  {
> > +    { Bad_Opcode },
> > +    { PREFIX_TABLE(PREFIX_VEX_0F38F6_L_0) },  },
> > +  /* X86_64_EVEX_0F38F7 */
> > +  {
> > +    { Bad_Opcode },
> > +    { PREFIX_TABLE(PREFIX_VEX_0F38F7_L_0) },  },
> > +  /* X86_64_EVEX_0F3AF0 */
> > +  {
> > +    { Bad_Opcode },
> > +    { PREFIX_TABLE (PREFIX_VEX_0F3AF0_L_0) },  },
> 
> Am I misremembering that we had agreed that this new file isn't necessary, by
> having USE_X86_64_EVEX_FROM_VEX_TABLE handle the non-64-bit case? At
> least I couldn't find a mail from you saying this isn't possible (and why).
> 
I Prefer not to change the current implement, we need a table that all instructions must go through, it can be x86-64 or len_table,
but I think x86-64 is better. It can reuse more old parts of x86-64 (for example X86_64_VEX_0F38E*) than len_table. If we use len_table instead, we need to let another 18 instructions through the len_table, this will also add the number of entries.

18 instructions are:
X86_64_VEX_0F38E0~ X86_64_VEX_0F38EF, X86_64_VEX_0F3849, and X86_64_VEX_0F384B.

Thanks,
Lili.