[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