From: Jan Beulich <jbeulich@suse.com>
To: Binutils <binutils@sourceware.org>
Cc: "H.J. Lu" <hjl.tools@gmail.com>
Subject: [PATCH 3/3] x86: move reg_operands adjustment
Date: Fri, 20 Jan 2023 11:00:54 +0100 [thread overview]
Message-ID: <44a44856-b7b2-5236-9d5e-6c681fc0fb82@suse.com> (raw)
In-Reply-To: <fa0b2985-f8b4-fe55-d657-1dc2ba2a1e4f@suse.com>
Ideally we'd do away with this somewhat questionable adjustment (leaving
i.types[] untouched). That's non-trivial though as it looks, so only
- move the logic into process_operands(), putting it closer to related
logic and eliminating a conditional for operand-less insns,
- make it consistent (i.e. also affect %xmm0), eliminating an ugly
special case later in the function.
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -5317,14 +5317,6 @@ md_assemble (char *line)
if (i.types[0].bitfield.imm1)
i.imm_operands = 0; /* kludge for shift insns. */
- /* We only need to check those implicit registers for instructions
- with 3 operands or less. */
- if (i.operands <= 3)
- for (j = 0; j < i.operands; j++)
- if (i.types[j].bitfield.instance != InstanceNone
- && !i.types[j].bitfield.xmmword)
- i.reg_operands--;
-
/* For insns with operands there are more diddles to do to the opcode. */
if (i.operands)
{
@@ -7936,6 +7928,13 @@ process_operands (void)
unnecessary segment overrides. */
const reg_entry *default_seg = NULL;
+ /* We only need to check those implicit registers for instructions
+ with 3 operands or less. */
+ if (i.operands <= 3)
+ for (unsigned int j = 0; j < i.operands; j++)
+ if (i.types[j].bitfield.instance != InstanceNone)
+ i.reg_operands--;
+
if (i.tm.opcode_modifier.sse2avx)
{
/* Legacy encoded insns allow explicit REX prefixes, so these prefixes
@@ -7970,6 +7969,7 @@ process_operands (void)
sources. */
i.tm.operand_types[0].bitfield.instance = InstanceNone;
i.tm.operand_types[0].bitfield.class = RegSIMD;
+ i.reg_operands++;
goto duplicate;
}
@@ -8025,11 +8025,6 @@ process_operands (void)
{
unsigned int j;
- /* This needs to account for the adjustment already done ahead of
- calling process_operands(). */
- if (i.tm.operand_types[0].bitfield.xmmword)
- i.reg_operands--;
-
for (j = 1; j < i.operands; j++)
{
i.op[j - 1] = i.op[j];
@@ -8042,6 +8037,8 @@ process_operands (void)
i.flags[j - 1] = i.flags[j];
}
+ /* No adjustment to i.reg_operands: This was already done at the top
+ of the function. */
i.operands--;
i.tm.operands--;
}
prev parent reply other threads:[~2023-01-20 10:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-20 9:58 [PATCH 0/3] x86: assorted tidying of opcode/operand handling Jan Beulich
2023-01-20 10:00 ` [PATCH 1/3] x86: use ModR/M for FPU insns with operands Jan Beulich
2023-01-20 10:00 ` [PATCH 2/3] x86: drop dead SSE2AVX-related code Jan Beulich
2023-01-20 10:00 ` Jan Beulich [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=44a44856-b7b2-5236-9d5e-6c681fc0fb82@suse.com \
--to=jbeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=hjl.tools@gmail.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).