public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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 }


  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).