RE: [PATCH] Support APX NF

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

> On 27.02.2024 10:01, Cui, Lili wrote:
> > @@ -1888,7 +1892,7 @@ static INLINE bool need_evex_encoding (const
> insn_template *t)
> >    return i.encoding == encoding_evex
> >  	|| i.encoding == encoding_evex512
> >  	|| (t->opcode_modifier.vex && i.has_egpr)
> > -	|| i.mask.reg;
> > +	|| i.mask.reg || i.has_nf;
> >  }
> 
> This, at least, can be avoided if ...
> 
> > @@ -7187,6 +7198,10 @@ parse_insn (const char *line, char *mnemonic,
> bool prefix_only)
> >  		  /* {rex2} */
> >  		  i.rex2_encoding = true;
> >  		  break;
> > +		case Prefix_NF:
> > +		  /* {NF} */
> > +		  i.has_nf = true;
> > +		  break;
> 
> .. you suitably update i.encoding here.
> 
> Which reminds me of another aspect wanting testing: Either order of {nf} and
> {vex} together wants proving that it is properly rejected. Note that this is
> different from a programmer using both {vex} and {evex}, where the latter
> simply overrides the earlier. (While this is reasonable behavior imo, this isn't
> to say that this is the only way of reasonably dealing with such. But that's the
> way things have been.)
> 

Ok, it is reasonable.

Thanks,
Lili.