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

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

> > 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;
+    }

> >>> @@ -10398,6 +10402,7 @@ putop (instr_info *ins, const char
> >>> *in_template,
> >> int sizeflag)
> >>>    int cond = 1;
> >>>    unsigned int l = 0, len = 0;
> >>>    char last[4];
> >>> +  bool b_done = false;
> >>
> >> Mind me asking what "b" in this identifier is intended to stand for?
> >>
> >
> > I just want to show that it is a bool type. Maybe it would be better to
> change it to b_added_evex_prefix? Do you have any suggestions?
> 
> I don't think we use such b_ prefixes elsewhere. "evex_printed" or some such
> would seem sufficient.
> 

Done.

> >>> @@ -10588,7 +10604,11 @@ putop (instr_info *ins, const char
> >> *in_template, int sizeflag)
> >>>  		  oappend (ins, "{nf} ");
> >>>  		  /* This bit needs to be cleared after it is consumed.  */
> >>>  		  ins->vex.nf = false;
> >>> +		  b_done = true;
> >>>  		}
> >>> +	      else if (ins->evex_type == evex_from_vex && !(ins->rex2 & 7)
> >>> +		       && ins->vex.v)
> >>> +		oappend (ins, "{evex} ");
> >>
> >> Why would b_done not need setting here as well?
> >>
> >
> > We only use b_done under "ins->evex_type == evex_from_legacy".
> Original version, we also handle "evex_from_legacy" here, now it is merged
> directly into "default:".
> 
> Then leaving a trap for later? Let's keep internal state properly updated:
> If {evex} is printed, reflect that in local variable state, too.
> 
Done.

 Thanks,
Lili.