From: Jan Beulich <jbeulich@suse.com>
To: "Cui, Lili" <lili.cui@intel.com>
Cc: hongjiu.lu@intel.com, binutils@sourceware.org
Subject: Re: [PATCH v4 3/9] Support APX GPR32 with extend evex prefix
Date: Fri, 22 Dec 2023 15:19:57 +0100 [thread overview]
Message-ID: <4c64e863-22a3-43e4-a566-e05c7fb909bd@suse.com> (raw)
In-Reply-To: <20231219121218.974012-4-lili.cui@intel.com>
On 19.12.2023 13:12, Cui, Lili wrote:
> --- a/opcodes/i386-dis-evex-prefix.h
> +++ b/opcodes/i386-dis-evex-prefix.h
> @@ -285,6 +285,14 @@
> { "%XEvfmsub213s%XW", { XMScalar, VexScalar, EXdq, EXxEVexR }, 0 },
> { "v4fnmadds%XS", { XMScalar, VexScalar, Mxmm }, 0 },
> },
> + /* PREFIX_EVEX_0F38F2_L_0 */
> + {
> + { "andnS", { Gdq, VexGdq, Edq }, 0 },
> + },
So not being able to re-use the VEX entry for this and ...
> --- a/opcodes/i386-dis-evex-reg.h
> +++ b/opcodes/i386-dis-evex-reg.h
> @@ -49,3 +49,10 @@
> { "vscatterpf0qp%XW", { MVexVSIBQWpX }, PREFIX_DATA },
> { "vscatterpf1qp%XW", { MVexVSIBQWpX }, PREFIX_DATA },
> },
> + /* REG_EVEX_0F38F3_L_0_P_0 */
> + {
> + { Bad_Opcode },
> + { "blsrS", { VexGdq, Edq }, 0 },
> + { "blsmskS", { VexGdq, Edq }, 0 },
> + { "blsiS", { VexGdq, Edq }, 0 },
> + },
... this was due to the VEX entries having PREFIX_OPCODE, which would be
getting in the way? This is the sort of thing that would be useful to
have in the description, to avoid raising the same question again that
(I think) was raised before.
Yet then - why do you strip PREFIX_OPCODE from the VEX entries? If you
do that (as iirc I did suggest), there's no need for having separate EVEX
ones (the suggestion, after all, was to be able to re-use the VEX
entries). That re-work of existing VEX encodings could, btw, also have
been split out quite easily. That way this huge patch would have further
shrunk a little.
> --- /dev/null
> +++ b/opcodes/i386-dis-evex-x86-64.h
> @@ -0,0 +1,50 @@
> + /* X86_64_EVEX_0F90 */
> + {
> + { Bad_Opcode },
> + { VEX_W_TABLE (VEX_W_0F90_L_0) },
> + },
> + /* X86_64_EVEX_0F91 */
> + {
> + { Bad_Opcode },
> + { VEX_W_TABLE (VEX_W_0F91_L_0) },
> + },
> + /* X86_64_EVEX_0F92 */
> + {
> + { Bad_Opcode },
> + { VEX_W_TABLE (VEX_W_0F92_L_0) },
> + },
> + /* X86_64_EVEX_0F93 */
> + {
> + { Bad_Opcode },
> + { VEX_W_TABLE (VEX_W_0F93_L_0) },
> + },
> + /* X86_64_EVEX_0F38F2 */
> + {
> + { Bad_Opcode },
> + { PREFIX_TABLE (PREFIX_VEX_0F38F2_L_0) },
> + },
> + /* X86_64_EVEX_0F38F3 */
> + {
> + { Bad_Opcode },
> + { PREFIX_TABLE (PREFIX_VEX_0F38F3_L_0) },
> + },
> + /* X86_64_EVEX_0F38F5 */
> + {
> + { Bad_Opcode },
> + { PREFIX_TABLE (PREFIX_VEX_0F38F5_L_0) },
> + },
> + /* X86_64_EVEX_0F38F6 */
> + {
> + { Bad_Opcode },
> + { PREFIX_TABLE(PREFIX_VEX_0F38F6_L_0) },
> + },
> + /* X86_64_EVEX_0F38F7 */
> + {
> + { Bad_Opcode },
> + { PREFIX_TABLE(PREFIX_VEX_0F38F7_L_0) },
> + },
> + /* X86_64_EVEX_0F3AF0 */
> + {
> + { Bad_Opcode },
> + { PREFIX_TABLE (PREFIX_VEX_0F3AF0_L_0) },
> + },
Am I misremembering that we had agreed that this new file isn't necessary,
by having USE_X86_64_EVEX_FROM_VEX_TABLE handle the non-64-bit case? At
least I couldn't find a mail from you saying this isn't possible (and why).
Jan
next prev parent reply other threads:[~2023-12-22 14:20 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-19 12:12 [PATCH v4 0/9] Support Intel APX EGPR Cui, Lili
2023-12-19 12:12 ` [PATCH v4 1/9] Support APX GPR32 with rex2 prefix Cui, Lili
2023-12-22 13:08 ` Jan Beulich
2023-12-25 6:14 ` Cui, Lili
2024-01-04 8:57 ` Jan Beulich
2023-12-19 12:12 ` [PATCH v4 2/9] Created an empty EVEX_MAP4_ sub-table for EVEX instructions Cui, Lili
2023-12-19 12:12 ` [PATCH v4 3/9] Support APX GPR32 with extend evex prefix Cui, Lili
2023-12-22 13:49 ` Jan Beulich
2023-12-25 12:23 ` Cui, Lili
2024-01-04 9:08 ` Jan Beulich
2024-01-04 12:32 ` Cui, Lili
2024-01-04 12:55 ` Jan Beulich
2023-12-22 14:19 ` Jan Beulich [this message]
2023-12-26 7:00 ` Cui, Lili
2024-01-04 9:01 ` Jan Beulich
2024-01-04 12:47 ` Cui, Lili
2023-12-19 12:12 ` [PATCH v4 4/9] Add tests for " Cui, Lili
2023-12-22 14:41 ` Jan Beulich
2023-12-25 13:40 ` Cui, Lili
2024-01-04 9:16 ` Jan Beulich
2024-01-05 6:58 ` Cui, Lili
2023-12-19 12:12 ` [PATCH v4 5/9] Support APX NDD Cui, Lili
2023-12-19 12:12 ` [PATCH v4 6/9] Support APX Push2/Pop2 Cui, Lili
2023-12-19 12:12 ` [PATCH v4 7/9] Support APX PUSHP/POPP Cui, Lili
2023-12-19 12:12 ` [PATCH v4 `8/9] Support APX NDD optimized encoding Cui, Lili
2023-12-19 12:12 ` [PATCH v4 9/9] Support APX JMPABS for disassembler Cui, Lili
2023-12-19 12:35 ` [PATCH v4 0/9] Support Intel APX EGPR Jan Beulich
2023-12-20 8:50 ` Cui, Lili
2023-12-20 8:57 ` Jan Beulich
2023-12-20 10:42 ` Cui, Lili
2023-12-20 11:00 ` Jan Beulich
2023-12-20 11:50 ` Cui, Lili
2023-12-20 12:01 ` Jan Beulich
2023-12-20 12:16 ` 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=4c64e863-22a3-43e4-a566-e05c7fb909bd@suse.com \
--to=jbeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=hongjiu.lu@intel.com \
--cc=lili.cui@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).