[PATCH V2] Support {evex} pseudo prefix for decode evex promoted insns without egpr32.

[Cui, Lili]

> On 08.04.2024 08:15, Cui, Lili wrote:
> >>> For pop2 %rax,%r8, it only has EVEX format, it's special because its
> >>> ins- vex.nd != 0,so the normal process will not add {evex} to it,
> >>> but we give it an
> >> illegal value, let ins->vex.nd = 0, so it added {evex} by mistake.
> >> This mistake is caused by illegal values. I don’t have a reasonable
> >> fix, so I prefer not to change it.
> >>> ------------------------------------------------------------------------------------
> >>>         # pop2 %rax, %r8 set EVEX.ND=0.
> >>>         .byte 0x62, 0xf4, 0x3c, 0x08, 0x8f, 0xc0
> >>>         .byte 0xff, 0xff, 0xff
> >>> --------------------------------------------------------------------
> >>> --
> >>> ---------------
> >>
> >> The POP2 aspect isn't really relevant here. Imo (bad) should never be
> >> prefixed by (pseudo) prefixes. If, however, it is to be, then such
> >> prefixing needs doing consistently. Which I'm afraid is going to be
> >> quite a bit more work than simply zapping (or avoiding) {evex} when (bad)
> is printed.
> >>
> >
> > I added an early return in "putop()" when the instruction name is "(bad)".
> Since we don't want to add any prefix or suffix to "(bad)". Do you think it is
> okay?
> >
> > @@ -10391,6 +10395,15 @@ putop (instr_info *ins, const char
> *in_template, int sizeflag)
> >    int cond = 1;
> >    unsigned int l = 0, len = 0;
> >    char last[4];
> >    bool evex_printed = false;
> >
> > +  if (!strncmp (in_template, "(bad)", 5))
> > +    {
> > +      oappend (ins, "(bad)");
> > +      *ins->obufp = 0;
> > +      ins->mnemonicendp = ins->obufp;
> > +      return 0;
> > +    }
> 
> At the first glance I'd say that's acceptable, provided a comment gets added.
> 

Added.

Lili.