From: Jan Beulich <jbeulich@suse.com>
To: Binutils <binutils@sourceware.org>
Cc: "H.J. Lu" <hjl.tools@gmail.com>
Subject: [PATCH 1/4] x86/Intel: restrict use of LONG_DOUBLE_MNEM_SUFFIX
Date: Wed, 30 Nov 2022 09:54:43 +0100 [thread overview]
Message-ID: <3d8c5353-723d-31ec-8efa-ee4fc994eaec@suse.com> (raw)
In-Reply-To: <b309d824-01de-72fd-6eaf-f82475acfc02@suse.com>
As a comment near the top of match_template() already says: We really
only need this pseudo-suffix for far branch handling. Stop "deriving" it
for floating point insns. (Don't bother renaming the now properly
misnamed LONG_DOUBLE_MNEM_SUFFIX, to e.g. FAR_BRANCH_SUFFIX - it's going
to disappear anyway.)
--- a/gas/config/tc-i386-intel.c
+++ b/gas/config/tc-i386-intel.c
@@ -749,13 +749,13 @@ i386_intel_operand (char *operand_string
case O_tbyte_ptr:
i.types[this_operand].bitfield.tbyte = 1;
- if (got_a_float == 1)
- suffix = LONG_DOUBLE_MNEM_SUFFIX;
- else if ((current_templates->start->operand_types[0].bitfield.fword
- || current_templates->start->operand_types[0].bitfield.tbyte
- || current_templates->start->opcode_modifier.jump == JUMP_DWORD
- || current_templates->start->opcode_modifier.jump == JUMP)
- && flag_code == CODE_64BIT)
+ if (got_a_float)
+ break;
+ if (flag_code == CODE_64BIT
+ && (current_templates->start->operand_types[0].bitfield.fword
+ || current_templates->start->operand_types[0].bitfield.tbyte
+ || current_templates->start->opcode_modifier.jump == JUMP_DWORD
+ || current_templates->start->opcode_modifier.jump == JUMP))
suffix = QWORD_MNEM_SUFFIX; /* l[fgs]s, [ls][gi]dt, call, jmp */
else
i.types[this_operand].bitfield.byte = 1; /* cause an error */
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -607,12 +607,12 @@ fld, 0xd9c0, None, CpuFP, NoSuf, { Float
fld, 0xd9, 0, CpuFP, Modrm|FloatMF|No_bSuf|No_wSuf|No_qSuf|No_ldSuf, { Dword|Qword|Unspecified|BaseIndex }
fld, 0xd9c0, None, CpuFP, IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|Ugh, { FloatReg }
// Intel Syntax
-fld, 0xdb, 5, CpuFP, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Tbyte|Unspecified|BaseIndex }
+fld, 0xdb, 5, CpuFP, Modrm|NoSuf, { Tbyte|Unspecified|BaseIndex }
fild, 0xdf, 0, CpuFP, Modrm|FloatMF|No_bSuf|No_wSuf|No_qSuf|No_ldSuf, { Word|Dword|Unspecified|BaseIndex }
fild, 0xdf, 5, CpuFP, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64, { Qword|Unspecified|BaseIndex }
fildll, 0xdf, 5, CpuFP, Modrm|NoSuf|ATTSyntax, { Unspecified|BaseIndex }
fldt, 0xdb, 5, CpuFP, Modrm|NoSuf, { Unspecified|BaseIndex }
-fbld, 0xdf, 4, CpuFP, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Tbyte|Unspecified|BaseIndex }
+fbld, 0xdf, 4, CpuFP, Modrm|NoSuf, { Tbyte|Unspecified|BaseIndex }
// store (no pop)
fst, 0xddd0, None, CpuFP, NoSuf, { FloatReg }
@@ -625,12 +625,12 @@ fstp, 0xddd8, None, CpuFP, NoSuf, { Floa
fstp, 0xd9, 3, CpuFP, Modrm|FloatMF|No_bSuf|No_wSuf|No_qSuf|No_ldSuf, { Dword|Qword|Unspecified|BaseIndex }
fstp, 0xddd8, None, CpuFP, IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf|No_ldSuf|Ugh, { FloatReg }
// Intel Syntax
-fstp, 0xdb, 7, CpuFP, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Tbyte|Unspecified|BaseIndex }
+fstp, 0xdb, 7, CpuFP, Modrm|NoSuf, { Tbyte|Unspecified|BaseIndex }
fistp, 0xdf, 3, CpuFP, Modrm|FloatMF|No_bSuf|No_wSuf|No_qSuf|No_ldSuf, { Word|Dword|Unspecified|BaseIndex }
fistp, 0xdf, 7, CpuFP, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_ldSuf|NoRex64, { Qword|Unspecified|BaseIndex }
fistpll, 0xdf, 7, CpuFP, Modrm|NoSuf|ATTSyntax, { Unspecified|BaseIndex }
fstpt, 0xdb, 7, CpuFP, Modrm|NoSuf, { Unspecified|BaseIndex }
-fbstp, 0xdf, 6, CpuFP, Modrm|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Tbyte|Unspecified|BaseIndex }
+fbstp, 0xdf, 6, CpuFP, Modrm|NoSuf, { Tbyte|Unspecified|BaseIndex }
// exchange %st<n> with %st0
fxch, 0xd9c8, None, CpuFP, NoSuf, { FloatReg }
next prev parent reply other threads:[~2022-11-30 8:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-30 8:53 [PATCH 0/4] x86: get rid of LONG_DOUBLE_MNEM_SUFFIX and No_ldSuf Jan Beulich
2022-11-30 8:54 ` Jan Beulich [this message]
2022-11-30 8:55 ` [PATCH 2/4] x86/Intel: drop LONG_DOUBLE_MNEM_SUFFIX Jan Beulich
2022-11-30 8:55 ` [PATCH 3/4] x86: drop No_ldSuf Jan Beulich
2022-11-30 8:56 ` [PATCH 4/4] x86: rework of match_template()'s suffix checking Jan Beulich
2022-11-30 22:25 ` [PATCH 0/4] x86: get rid of LONG_DOUBLE_MNEM_SUFFIX and No_ldSuf H.J. Lu
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=3d8c5353-723d-31ec-8efa-ee4fc994eaec@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).