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 V2 3/8] Support APX GPR32 with extend evex prefix
Date: Thu, 9 Nov 2023 14:57:57 +0000 [thread overview]
Message-ID: <SJ0PR11MB56006329514A1F253E7B39DC9EAFA@SJ0PR11MB5600.namprd11.prod.outlook.com> (raw)
In-Reply-To: <fd2a9b03-2801-5973-24bc-8cc83fab9170@suse.com>
> >> To avoid the need to fiddle with this file, did you consider changing
> >> the test's command line options instead? In any event ...
> >>
> >
> > Do you mean disabling apx_f with the command line "#as..."?
>
> Yes.
>
> > I tried "#as -march=+noapx_f" , but not worked.
>
> Listing tests have their command line options passed directly from the .exp
> file.
>
It worked, thanks.
+run_list_test "x86-64-inval-movbe" "-I${srcdir}/$subdir -march=+noapx_f -al"
> >>> --- a/opcodes/i386-dis-evex-len.h
> >>> +++ b/opcodes/i386-dis-evex-len.h
> >>> @@ -62,6 +62,16 @@ static const struct dis386 evex_len_table[][3] = {
> >>> { REG_TABLE (REG_EVEX_0F38C7_L_2) },
> >>> },
> >>>
> >>> + /* EVEX_LEN_0F38F2 */
> >>> + {
> >>> + { "andnS", { Gdq, VexGdq, Edq }, 0 },
> >>> + },
> >>
> >> There's no sign of a prefix decode step here.
> >>
> >
> > The prefix decoding step is in the NF patch and its dependent patches (Part
> II 2/6). Both are suspended currently.
>
> But prefix decoding is orthogonal to NF handling. Why would that step be
> added only there?
>
In V1 NF patch, we treated {nf} as prefix, {evex} and {nf} need to be selected or empty.
"XN" => print "{nf} " pseudo prefix when EVEX.NF = 1. When EVEX.NF = 0 and under certain conditions, need to print {evex}
For XN:
if (ins->vex.nf == true)
{
*ins->obufp++ = '{';
*ins->obufp++ = 'n';
*ins->obufp++ = 'f';
*ins->obufp++ = '}';
*ins->obufp++ = ' ';
}
else if (ins->evex_type == evex_from_legacy && !ins->vex.b)
{
*ins->obufp++ = '{';
*ins->obufp++ = 'e';
*ins->obufp++ = 'v';
*ins->obufp++ = 'e';
*ins->obufp++ = 'x';
*ins->obufp++ = '}';
*ins->obufp++ = ' ';
}
Now there is a high probability that nf will be treated as suffix, the specific expression is still uncertain. Maybe we should add %XE to them in this patch. make sure its output is correct.
> >>> --- a/opcodes/i386-dis-evex-mod.h
> >>> +++ b/opcodes/i386-dis-evex-mod.h
> >>> @@ -1 +1,43 @@
> >>> /* Nothing at present. */
> >>
> >> This comment needs to go away when new stuff is added here. However,
> >> I'm sure I requested before that no new entries be put here which
> >> have only one of their two slots populated. The reg-only and mem-only
> >> aspects can be expressed via proper choice of operand specifiers, at least
> in almost all cases.
> >> Note how you already use ...
> >>
> >>> + /* MOD_EVEX_MAP4_DA_PREFIX_1 */
> >>> + {
> >>> + { Bad_Opcode },
> >>> + { "encodekey128", { Gd, Ed }, 0 }, },
> >>> + /* MOD_EVEX_MAP4_DB_PREFIX_1 */
> >>> + {
> >>> + { Bad_Opcode },
> >>> + { "encodekey256", { Gd, Ed }, 0 }, },
> >>> + /* MOD_EVEX_MAP4_DC_PREFIX_1 */
> >>> + {
> >>> + { "aesenc128kl", { XM, M }, 0 },
> >>> + },
> >>> + /* MOD_EVEX_MAP4_DD_PREFIX_1 */
> >>> + {
> >>> + { "aesdec128kl", { XM, M }, 0 },
> >>> + },
> >>> + /* MOD_EVEX_MAP4_DE_PREFIX_1 */
> >>> + {
> >>> + { "aesenc256kl", { XM, M }, 0 },
> >>> + },
> >>> + /* MOD_EVEX_MAP4_DF_PREFIX_1 */
> >>> + {
> >>> + { "aesdec256kl", { XM, M }, 0 },
> >>> + },
> >>> + /* MOD_EVEX_MAP4_F8_PREFIX_1 */
> >>> + {
> >>> + { "enqcmds", { Gva, M }, 0 },
> >>> + },
> >>> + /* MOD_EVEX_MAP4_F8_PREFIX_2 */
> >>> + {
> >>> + { "movdir64b", { Gva, M }, 0 },
> >>> + },
> >>> + /* MOD_EVEX_MAP4_F8_PREFIX_3 */
> >>> + {
> >>> + { "enqcmd", { Gva, M }, 0 },
> >>> + },
> >>
> >> ... M in many entries anyway. These can move one level up without
> >> needing further adjustment.
> >>
> >> For all of the above, however, an EVEX.W decode step looks to be missing.
> >> Interestingly the doc consistently omits the (presumably) .W0 suffix
> >> for these, having merely a trailing dot there. The issue (doc and/or
> >> code) is present elsewhere as well.
> >>
> >
> > Do you mean that all EVEX promoted instructions need to be explicitly
> > .W0 in the doc?
>
> Not exactly, no. The doc should explicitly state what the behavior wrt EVEX.W
> is. I'm merely guessing that for the insns where it's missing
> W0 might be meant (on the assumption that a common goal ought to be to
> waste as little encoding space as possible). If it's WIG (in the present doc
> typically spelled IGNORED) instead, ...
>
> > in the case of, I'll handle it uniformly in get_valid_dis386.
>
> ... no W decoding step would be needed of course.
>
Ok
Thanks,
Lili.
next prev parent reply other threads:[~2023-11-09 15:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-03 16:50 Cui, Lili
2023-11-06 17:07 ` Jan Beulich
2023-11-13 5:53 ` Cui, Lili
2023-11-13 8:34 ` Jan Beulich
2023-11-14 3:12 ` Cui, Lili
2023-11-14 10:29 ` Jan Beulich
2023-11-15 8:39 ` Cui, Lili
2023-11-07 13:29 ` Jan Beulich
2023-11-09 8:38 ` Cui, Lili
2023-11-09 11:07 ` Jan Beulich
2023-11-09 11:12 ` Jan Beulich
2023-11-07 14:53 ` Jan Beulich
2023-11-09 12:31 ` Cui, Lili
2023-11-09 13:05 ` Jan Beulich
2023-11-09 14:57 ` Cui, Lili [this message]
2023-11-09 15:39 ` Jan Beulich
2023-11-14 7:42 ` Cui, Lili
2023-11-14 10:40 ` Jan Beulich
2023-11-14 14:46 ` Cui, Lili
2023-11-15 6:03 ` Cui, Lili
2023-11-15 9:11 ` Jan Beulich
2023-11-15 11:43 ` Cui, Lili
2023-11-16 13:57 ` Jan Beulich
2023-11-16 15:10 ` Cui, Lili
2023-11-16 15:15 ` Jan Beulich
2023-11-16 16:12 ` 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=SJ0PR11MB56006329514A1F253E7B39DC9EAFA@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).