public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Cui, Lili" <lili.cui@intel.com>
To: "Beulich, Jan" <JBeulich@suse.com>
Cc: "Lu, Hongjiu" <hongjiu.lu@intel.com>,
	"binutils@sourceware.org" <binutils@sourceware.org>
Subject: RE: [PATCH 1/8] Support APX GPR32 with rex2 prefix
Date: Wed, 27 Sep 2023 15:59:11 +0000	[thread overview]
Message-ID: <SJ0PR11MB560056EEC553901B3A33E8329EC2A@SJ0PR11MB5600.namprd11.prod.outlook.com> (raw)
In-Reply-To: <dba13b89-c458-f749-9aea-7e009d666a7b@suse.com>

> >    /* Bits of REX we've already used.  */
> >    uint8_t rex_used;
> >
> > +  /* REX2 prefix for the current instruction use gpr32(r16-r31). */
> > + unsigned char rex2;
> > +  /* Bits of REX2 we've already used.  */  unsigned char rex2_used;
> 
> Since these two fields don't hold the REX2 bits directly, the comment(s)
> want(s) saying what they contain.
> 
> > +  unsigned char rex2_payload;
> 
> I don't see this field used in more than one function. In which case it can be a
> local variable there (in the innermost scope covering all uses).
> 
Yes, it should be local variable. Changed it.

> > @@ -367,6 +381,7 @@ fetch_error (const instr_info *ins)
> >  #define PREFIX_IGNORED_DATA	(PREFIX_DATA <<
> PREFIX_IGNORED_SHIFT)
> >  #define PREFIX_IGNORED_ADDR	(PREFIX_ADDR <<
> PREFIX_IGNORED_SHIFT)
> >  #define PREFIX_IGNORED_LOCK	(PREFIX_LOCK <<
> PREFIX_IGNORED_SHIFT)
> > +#define PREFIX_IGNORED_REX2	(PREFIX_REX2 <<
> PREFIX_IGNORED_SHIFT)
> 
> I don't think "ignored" is what you mean, considering ...
> 
> >      /* MOD_0FAE_REG_5 */
> > -    { "xrstor",		{ FXSAVE }, PREFIX_OPCODE },
> > +    { "xrstor",		{ FXSAVE }, PREFIX_OPCODE |
> PREFIX_IGNORED_REX2 },
> >      { PREFIX_TABLE (PREFIX_0FAE_REG_5_MOD_3) },
> >    },
> 
> ... these uses here.
> 

Replaced " PREFIX_IGNORED_REX2" with "ILLEGAL_PREFIX_REX2 ".

> >      case USE_EVEX_TABLE:
> > +      if (ins->last_rex2_prefix >= 0)
> > +	return &bad_opcode;
> >        ins->two_source_ops = false;
> >        /* EVEX prefix.  */
> >        ins->vex.evex = true;
> 
> There aren't similar REX checks here, yet both should be handled as similarly
> as possible.

Done.

> 
> > @@ -9292,13 +9344,17 @@ print_insn (bfd_vma pc, disassemble_info
> *info, int intel_syntax)
> >        goto out;
> >      }
> >
> > -  if (*ins.codep == 0x0f)
> > +  /* M0 in rex2 prefix represents map0 or map1.  */  if (*ins.codep
> > + == 0x0f || (ins.rex2 & 0x8))
> 
> Please can literals like the 0x8 here gain meaningful names (REX2_M in this
> case)?
> 

Done.

> > @@ -9468,6 +9532,7 @@ print_insn (bfd_vma pc, disassemble_info *info,
> int intel_syntax)
> >        ins.used_prefixes |= PREFIX_DATA;
> >        /* Fall through.  */
> >      case PREFIX_OPCODE:
> > +    case PREFIX_OPCODE | PREFIX_IGNORED_REX2:
> 
> You may rather want to mask off the high part in the switch() expression itself.

Tried it , found that 'Case PREFIX_IGNORED' uses the high part of this switch. 

#define PREFIX_IGNORED          (PREFIX_IGNORED_REPZ \
                                 | PREFIX_IGNORED_REPNZ \
                                 | PREFIX_IGNORED_DATA)

#define PREFIX_IGNORED_REPZ     (PREFIX_REPZ << PREFIX_IGNORED_SHIFT)
#define PREFIX_IGNORED_REPNZ    (PREFIX_REPNZ << PREFIX_IGNORED_SHIFT)
#define PREFIX_IGNORED_DATA     (PREFIX_DATA << PREFIX_IGNORED_SHIFT)

> > @@ -9510,9 +9575,17 @@ print_insn (bfd_vma pc, disassemble_info *info,
> > int intel_syntax)
> >
> >    /* Check if the REX prefix is used.  */
> >    if ((ins.rex ^ ins.rex_used) == 0
> > -      && !ins.need_vex && ins.last_rex_prefix >= 0)
> > +      && !ins.need_vex && ins.last_rex_prefix >= 0
> > +      && ins.last_rex2_prefix < 0)
> >      ins.all_prefixes[ins.last_rex_prefix] = 0;
> >
> > +  /* Check if the REX2 prefix is used.  */
> > +  if (ins.last_rex2_prefix >= 0
> > +      && ((((ins.rex2 & 0x7) ^ (ins.rex2_used & 0x7)) == 0
> > +	   && (ins.rex2 & 0x7))
> > +	  || dp == &bad_opcode))
> > +    ins.all_prefixes[ins.last_rex2_prefix] = 0;
> 
> I'm again puzzled by the dissimilarity with the REX handling. Furthermore,
> with the way you split the REX2 payload byte, I don't think the combination of
> REX and REX2 handling above will result in correct output in all cases.
> (There shouldn't be mention of an unused REX bit when REX2 was in use on
> an insn.)

Done.

> > @@ -11307,6 +11386,7 @@ static bool
> >  OP_E_memory (instr_info *ins, int bytemode, int sizeflag)  {
> >    int add = (ins->rex & REX_B) ? 8 : 0;
> > +  add += (ins->rex2 & REX_B) ? 16 : 0;
> >    int riprel = 0;
> >    int shift;
> 
> While generally mixing declaration and statements is okay nowadays, putting
> a statement in the middle of a block's initial declarations would imo still
> better be avoided.

Done.

Moved this comment from patch2/8 to here.
      if (modifiers[Vex].value
	  || (space > SPACE_0F
	      && space != SPACE_EVEXMAP4
	      && !modifiers[EVex].value
	      && !modifiers[Disp8MemShift].value
	      && !modifiers[Broadcast].value
	      && !modifiers[Masking].value
	      && !modifiers[SAE].value))
       }
	modifiers[No_egpr].value = 1;
      }

>And then - shouldn't at least part of this already be put in place in patch 1?
>Finally, to avoid the split between where this attribute gets set, wouldn't it be possible to also handle the XSAVE/XRSTOR variants here rather than directly in the opcode table?

I put part of this in patch 1, and add a new function to handle NoEgpr (the parameter's number of  process_i386_opcode_modifier is a bit too much, so I added a new function).
I merged partII patch2/6 into this patch. listed it with 3.

We handle the following in function if_entry_needs_special_handle():
1.  Prefixing XSAVE* and XRSTOR* instructions with REX2 triggers #UD.
2.  Disable Egpr for 3dnow and 3dnowA.
3.  All opcodes listed map0 0x4*, 0x7*, 0xa* and map0 0x3*, 0x8* are reserved under REX2 and triggers #UD when prefixed with REX2

Finally, thank you for checking these large patches so carefully. The next few days are China's national holidays, which last about 8 days, my feedback time will be longer. Thank you.

Lili.

> Jan

  reply	other threads:[~2023-09-27 15:59 UTC|newest]

Thread overview: 118+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-19 15:25 [PATCH 0/8] [RFC] Support Intel APX EGPR Cui, Lili
2023-09-19 15:25 ` [PATCH 1/8] Support APX GPR32 with rex2 prefix Cui, Lili
2023-09-21 15:27   ` Jan Beulich
2023-09-27 15:57     ` Cui, Lili
2023-09-21 15:51   ` Jan Beulich
2023-09-27 15:59     ` Cui, Lili [this message]
2023-09-28  8:02       ` Jan Beulich
2023-10-07  3:27         ` Cui, Lili
2023-09-19 15:25 ` [PATCH 2/8] Support APX GPR32 with extend evex prefix Cui, Lili
2023-09-22 10:12   ` Jan Beulich
2023-10-17 15:48     ` Cui, Lili
2023-10-18  6:40       ` Jan Beulich
2023-10-18 10:44         ` Cui, Lili
2023-10-18 10:50           ` Jan Beulich
2023-09-22 10:50   ` Jan Beulich
2023-10-17 15:50     ` Cui, Lili
2023-10-17 16:11       ` Jan Beulich
2023-10-18  2:02         ` Cui, Lili
2023-10-18  6:10           ` Jan Beulich
2023-09-25  6:03   ` Jan Beulich
2023-10-17 15:52     ` Cui, Lili
2023-10-17 16:12       ` Jan Beulich
2023-10-18  6:31         ` Cui, Lili
2023-10-18  6:47           ` Jan Beulich
2023-10-18  7:52             ` Cui, Lili
2023-10-18  8:21               ` Jan Beulich
2023-10-18 11:30                 ` Cui, Lili
2023-10-19 11:58                   ` Cui, Lili
2023-10-19 15:24                     ` Jan Beulich
2023-10-19 16:38                       ` Cui, Lili
2023-10-20  6:25                         ` Jan Beulich
2023-10-22 14:33                           ` Cui, Lili
2023-09-19 15:25 ` [PATCH 3/8] Add tests for " Cui, Lili
2023-09-27 13:11   ` Jan Beulich
2023-10-17 15:53     ` FW: " Cui, Lili
2023-10-17 16:19       ` Jan Beulich
2023-10-18  2:32         ` Cui, Lili
2023-10-18  6:05           ` Jan Beulich
2023-10-18  7:16             ` Cui, Lili
2023-10-18  8:05               ` Jan Beulich
2023-10-18 11:26                 ` Cui, Lili
2023-10-18 12:06                   ` Jan Beulich
2023-10-25 16:03                     ` Cui, Lili
2023-09-27 13:19   ` Jan Beulich
2023-09-19 15:25 ` [PATCH 4/8] Support APX NDD Cui, Lili
2023-09-27 14:44   ` Jan Beulich
2023-10-22 14:05     ` Cui, Lili
2023-10-23  7:12       ` Jan Beulich
2023-10-25  8:10         ` Cui, Lili
2023-10-25  8:47           ` Jan Beulich
2023-10-25 15:49             ` Cui, Lili
2023-10-25 15:59               ` Jan Beulich
2023-09-28  7:57   ` Jan Beulich
2023-10-22 14:57     ` Cui, Lili
2023-10-24 11:39     ` Cui, Lili
2023-10-24 11:58       ` Jan Beulich
2023-10-25 15:29         ` Cui, Lili
2023-09-19 15:25 ` [PATCH 5/8] Support APX NDD optimized encoding Cui, Lili
2023-09-28  9:29   ` Jan Beulich
2023-10-23  2:57     ` Hu, Lin1
2023-10-23  7:23       ` Jan Beulich
2023-10-23  7:50         ` Hu, Lin1
2023-10-23  8:15           ` Jan Beulich
2023-10-24  1:40             ` Hu, Lin1
2023-10-24  6:03               ` Jan Beulich
2023-10-24  6:08                 ` Hu, Lin1
2023-10-23  3:07     ` [PATCH-V2] " Hu, Lin1
2023-10-23  3:30     ` [PATCH 5/8] [v2] " Hu, Lin1
2023-10-23  7:26       ` Jan Beulich
2023-09-19 15:25 ` [PATCH 6/8] Support APX Push2/Pop2 Cui, Lili
2023-09-28 11:37   ` Jan Beulich
2023-10-30 15:21     ` Cui, Lili
2023-10-30 15:31       ` Jan Beulich
2023-11-20 13:05         ` Cui, Lili
2023-09-19 15:25 ` [PATCH 7/8] Support APX NF Cui, Lili
2023-09-25  6:07   ` Jan Beulich
2023-09-28 12:42   ` Jan Beulich
2023-11-02 10:15     ` Cui, Lili
2023-11-02 10:23       ` Jan Beulich
2023-11-02 10:46         ` Cui, Lili
2023-12-12  2:59           ` H.J. Lu
2023-09-19 15:25 ` [PATCH 8/8] Support APX JMPABS Cui, Lili
2023-09-28 13:11   ` Jan Beulich
2023-11-02  2:32     ` Hu, Lin1
2023-11-02 11:29 [PATCH v2 0/8] Support Intel APX EGPR Cui, Lili
2023-11-02 11:29 ` [PATCH 1/8] Support APX GPR32 with rex2 prefix Cui, Lili
2023-11-02 17:05   ` Jan Beulich
2023-11-03  6:20     ` Cui, Lili
2023-11-03 13:05     ` Jan Beulich
2023-11-03 14:19   ` Jan Beulich
2023-11-06 15:20     ` Cui, Lili
2023-11-06 16:08       ` Jan Beulich
2023-11-07  8:16         ` Cui, Lili
2023-11-07 10:43           ` Jan Beulich
2023-11-07 15:31             ` Cui, Lili
2023-11-07 15:43               ` Jan Beulich
2023-11-07 15:53                 ` Cui, Lili
2023-11-06 15:02   ` Jan Beulich
2023-11-07  8:06     ` Cui, Lili
2023-11-07 10:20       ` Jan Beulich
2023-11-07 14:32         ` Cui, Lili
2023-11-07 15:08           ` Jan Beulich
2023-11-06 15:39   ` Jan Beulich
2023-11-09  8:02     ` Cui, Lili
2023-11-09 10:52       ` Jan Beulich
2023-11-09 13:27         ` Cui, Lili
2023-11-09 15:22           ` Jan Beulich
2023-11-10  7:11             ` Cui, Lili
2023-11-10  9:14               ` Jan Beulich
2023-11-10  9:21                 ` Jan Beulich
2023-11-10 12:38                   ` Cui, Lili
2023-12-14 10:13                   ` Cui, Lili
2023-12-18 15:24                     ` Jan Beulich
2023-12-18 16:23                       ` H.J. Lu
2023-11-10  9:47                 ` Cui, Lili
2023-11-10  9:57                   ` Jan Beulich
2023-11-10 12:05                     ` Cui, Lili
2023-11-10 12:35                       ` Jan Beulich
2023-11-13  0:18                         ` Cui, Lili

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR11MB560056EEC553901B3A33E8329EC2A@SJ0PR11MB5600.namprd11.prod.outlook.com \
    --to=lili.cui@intel.com \
    --cc=JBeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=hongjiu.lu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).