[PATCH V5] Support APX NF

Cui, Lili lili.cui@intel.com
Sun Apr 7 02:34:47 GMT 2024


> On 01.04.2024 08:24, Cui, Lili wrote:
> > --- a/gas/testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d
> > +++ b/gas/testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d
> > @@ -21,14 +21,12 @@ Disassembly of section .text:
> >  [ 	]*[a-f0-9]+:[ 	]+62 fc 7d[ 	]+\(bad\).*
> >  [ 	]*[a-f0-9]+:[ 	]+28 60 c7[ 	]+.*
> >  [ 	]*[a-f0-9]+:[ 	]+62 fc 7d[ 	]+\(bad\).*
> > -[ 	]*[a-f0-9]+:[ 	]+8f[ 	]+\(bad\)
> > -[ 	]*[a-f0-9]+:[ 	]+60[ 	]+\(bad\)
> > -[ 	]*[a-f0-9]+:[ 	]+c7[ 	]+\(bad\)
> > +[ 	]*[a-f0-9]+:[ 	]+8b 60 c7[ 	]+.*
> >  [ 	]*[a-f0-9]+:[ 	]+62 f2 fc 09 f5[ 	]+\(bad\).*
> >  [ 	]*[a-f0-9]+:[ 	]+0c 18[ 	]+or.*
> >  [ 	]*[a-f0-9]+:[ 	]+62 f2 fc 28 f5[ 	]+\(bad\)
> >  [ 	]*[a-f0-9]+:[ 	]+0c 18[ 	]+or.*
> > -[ 	]*[a-f0-9]+:[ 	]+62 f2 fc 8f f5[ 	]+\(bad\).*
> > +[ 	]*[a-f0-9]+:[ 	]+62 f2 fc 8b f5[ 	]+\(bad\).*
> >  [ 	]*[a-f0-9]+:[ 	]+0c 18[ 	]+or.*
> >  [ 	]*[a-f0-9]+:[ 	]+62 f2 fc 18 f5[ 	]+\(bad\)
> >  [ 	]*[a-f0-9]+:[ 	]+0c 18[ 	]+or.*
> > @@ -43,4 +41,5 @@ Disassembly of section .text:
> >  [ 	]*[a-f0-9]+:[ 	]+62 e4 7e 08 dc 20[ 	]+aesenc128kl
> \(%rax\),%xmm20\(bad\)
> >  [ 	]*[a-f0-9]+:[ 	]+62 b4 7c 08 d9 c4[
> 	]+sha1msg1 %xmm20\(bad\),%xmm0
> >  [ 	]*[a-f0-9]+:[ 	]+62 e4 7c 08 d9 20[ 	]+sha1msg1
> \(%rax\),%xmm20\(bad\)
> > +[ 	]*[a-f0-9]+:[ 	]+62 fc 7d 0c 60 c7[ 	]+movbe  \{bad\-
> nf\},%r23w,%ax
> 
> A dash doesn't need escaping, does it?
> 
> Okay with this either clarified verbally, or adjusted.
> 

Adjusted.

> > @@ -9600,6 +9605,15 @@ print_insn (bfd_vma pc, disassemble_info *info,
> int intel_syntax)
> >  	  && ins.vex.prefix == DATA_PREFIX_OPCODE)
> >  	sizeflag ^= DFLAG;
> >
> > +      if(ins.evex_type == evex_default)
> > +	ins.vex.nf = false;
> > +      else
> > +	/* For EVEX-promoted formats, we need to clear EVEX.NF (For ccmp
> and
> > +	   ctest, they will be cleared separately.) in mask_register_specifier
> > +	   and keep the low 2 bits of mask_register_specifier to report errors
> > +	   for invalid cases.*/
> > +	ins.vex.mask_register_specifier &= 0x3;
> 
> Just as a remark: "will be" in the comment is liable to need updating once
> that code is actually added. Please make yourself a note to check that, as it'll
> be close to impossible to spot while reviewing.
> 

Changed.

> Also, as another general remark: Please may I remind you to help review by
> making available a brief revision log, relative to at least the immediate earlier
> patch version? While you have "Rebased nf patch with master" at the very
> top, that neither belongs there, nor is it (imo) really describing what changes
> you have done.
> 

Ok.

Thanks,
Lili.


More information about the Binutils mailing list