From: "Cui, Lili" <lili.cui@intel.com>
To: "Beulich, Jan" <JBeulich@suse.com>, "Hu, Lin1" <lin1.hu@intel.com>
Cc: "hjl.tools@gmail.com" <hjl.tools@gmail.com>,
"binutils@sourceware.org" <binutils@sourceware.org>
Subject: RE: [PATCH] Support {evex} pseudo prefix for decode evex promoted insns without egpr32.
Date: Fri, 22 Mar 2024 09:45:46 +0000 [thread overview]
Message-ID: <SJ0PR11MB560050FBD30E3ECB2D5084479E312@SJ0PR11MB5600.namprd11.prod.outlook.com> (raw)
In-Reply-To: <1b29c006-7ea6-40d4-ac7c-1c0b40c6243c@suse.com>
>
> > --- a/opcodes/i386-dis-evex-mod.h
> > +++ b/opcodes/i386-dis-evex-mod.h
> > @@ -1,10 +1,10 @@
> > /* MOD_EVEX_MAP4_F8_P1 */
> > {
> > - { "enqcmds", { Gva, M }, 0 },
> > - { "uwrmsr", { Gq, Eq }, 0 },
> > + { "%XEenqcmds", { Gva, M }, 0 },
> > + { "%XEuwrmsr", { Gq, Eq }, 0 },
> > },
> > /* MOD_EVEX_MAP4_F8_P3 */
> > {
> > - { "enqcmd", { Gva, M }, 0 },
> > - { "urdmsr", { Eq, Gq }, 0 },
> > + { "%XEenqcmd", { Gva, M }, 0 },
> > + { "%XEurdmsr", { Eq, Gq }, 0 },
> > },
>
> Hmm. Once new encodings appear in Map4, I can see that we will need such
> distinction. But right now can't we get away without touching all of them
> again, by simply taking it being Map4 as an indication? The only place where it
> may be helpful to indeed add all of these right away is MOVBE, where its
> register form then would not have %XE added.
>
Good idea, overall judgment can avoid missing instructions( found crc32 missing %XE).
> > --- a/opcodes/i386-dis-evex-reg.h
> > +++ b/opcodes/i386-dis-evex-reg.h
> > @@ -53,8 +53,8 @@
> > {
> > { "%NFaddA", { VexGb, Eb, Ib }, NO_PREFIX },
> > { "%NForA", { VexGb, Eb, Ib }, NO_PREFIX },
> > - { "adcA", { VexGb, Eb, Ib }, NO_PREFIX },
> > - { "sbbA", { VexGb, Eb, Ib }, NO_PREFIX },
> > + { "%XEadcA", { VexGb, Eb, Ib }, NO_PREFIX },
> > + { "%XEsbbA", { VexGb, Eb, Ib }, NO_PREFIX },
> > { "%NFandA", { VexGb, Eb, Ib }, NO_PREFIX },
> > { "%NFsubA", { VexGb, Eb, Ib }, NO_PREFIX },
> > { "%NFxorA", { VexGb, Eb, Ib }, NO_PREFIX },
>
> IOW this patch goes on top of the NF one, without that being said anywhere?
> Except not quite, as ...
>
> > --- a/opcodes/i386-dis.c
> > +++ b/opcodes/i386-dis.c
> > @@ -2625,8 +2625,8 @@ static const struct dis386 reg_table[][8] = {
> > {
> > { "%NFrolA", { VexGb, Eb, Ib }, NO_PREFIX },
> > { "%NFrorA", { VexGb, Eb, Ib }, NO_PREFIX },
> > - { "rclA", { VexGb, Eb, Ib }, NO_PREFIX },
> > - { "rcrA", { VexGb, Eb, Ib }, NO_PREFIX },
> > + { "%XErclA", { VexGb, Eb, Ib }, NO_PREFIX },
> > + { "%XErcrA", { VexGb, Eb, Ib }, NO_PREFIX },
>
> ... that patch wrongly added %NF here. So looks like that patch was partly
> fixed already in this regard (the NOT adjustment there will then also need
> reflecting here). But please - anything like this needs making entirely
> transparent to the reader.
>
Ok.
> > @@ -10595,7 +10595,9 @@ putop (instr_info *ins, const char
> *in_template, int sizeflag)
> > *ins->obufp++ = '}';
> > *ins->obufp++ = ' ';
> > }
> > - else if (ins->evex_type == evex_from_legacy && !ins->vex.b)
> > + else if ((ins->evex_type == evex_from_legacy && !ins->vex.b)
> > + || (ins->evex_type == evex_from_vex
> > + && !((ins->rex2 & 7) || !ins->vex.v)))
>
> This double negation is hard to follow:
>
> else if ((ins->evex_type == evex_from_legacy && !ins->vex.b)
> || (ins->evex_type == evex_from_vex
> && !(ins->rex2 & 7) && ins->vex.v))
>
Done.
Thanks,
Lili.
prev parent reply other threads:[~2024-03-22 9:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 9:58 Cui, Lili
2024-03-08 10:37 ` Jan Beulich
2024-03-20 13:12 ` Cui, Lili
2024-03-20 13:21 ` Jan Beulich
2024-03-21 12:33 ` Cui, Lili
2024-03-22 9:45 ` Cui, Lili [this message]
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=SJ0PR11MB560050FBD30E3ECB2D5084479E312@SJ0PR11MB5600.namprd11.prod.outlook.com \
--to=lili.cui@intel.com \
--cc=JBeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=lin1.hu@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).