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 05/11] x86: respect ".arch nonop" when selecting which NOPs to emit
Date: Wed, 27 Sep 2023 17:50:17 +0200	[thread overview]
Message-ID: <a0856079-0bf9-20d7-bd62-8f5f20584251@suse.com> (raw)
In-Reply-To: <7ce54bc2-fef2-d2e4-21fd-202fdead0c20@suse.com>

Making GENERIC64 a special case was never correct; prior to the
generalization of ".arch .no*" to cover all ISA extensions other
processor families supporting long NOPs should have been covered as
well. When introducing ".arch .nonops" (among others) it wasn't
apparent that a hidden implication of .cpunop not being possible to
separately turn off existed here. Seeing that the two large case label
blocks in the 2nd switch() already had identical behavior, simply
collapse all of the (useful) case labels into a single "default" one.

--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -802,7 +802,7 @@ static const char *cpu_arch_name = NULL;
 static char *cpu_sub_arch_name = NULL;
 
 /* CPU feature flags.  */
-static i386_cpu_flags cpu_arch_flags = CPU_UNKNOWN_FLAGS;
+i386_cpu_flags cpu_arch_flags = CPU_UNKNOWN_FLAGS;
 
 /* If we have selected a cpu we are generating instructions for.  */
 static int cpu_arch_tune_set = 0;
@@ -1463,7 +1463,8 @@ i386_generate_nops (fragS *fragP, char *
       patt = fragP->tc_frag_data.code == CODE_64BIT ? f64_patt : f32_patt;
       if (fragP->tc_frag_data.isa == PROCESSOR_UNKNOWN)
 	{
-	  /* PROCESSOR_UNKNOWN means that all ISAs may be used.  */
+	  /* PROCESSOR_UNKNOWN means that all ISAs may be used, unless
+	     explicitly disabled.  */
 	  switch (fragP->tc_frag_data.tune)
 	    {
 	    case PROCESSOR_UNKNOWN:
@@ -1485,8 +1486,10 @@ i386_generate_nops (fragS *fragP, char *
 	    case PROCESSOR_BD:
 	    case PROCESSOR_ZNVER:
 	    case PROCESSOR_BT:
-	      patt = alt_patt;
+	      if (fragP->tc_frag_data.cpunop)
+		patt = alt_patt;
 	      break;
+
 	    case PROCESSOR_I386:
 	    case PROCESSOR_I486:
 	    case PROCESSOR_PENTIUM:
@@ -1508,35 +1511,13 @@ i386_generate_nops (fragS *fragP, char *
 	      abort ();
 	      break;
 
-	    case PROCESSOR_I386:
-	    case PROCESSOR_I486:
-	    case PROCESSOR_PENTIUM:
-	    case PROCESSOR_IAMCU:
-	    case PROCESSOR_K6:
-	    case PROCESSOR_ATHLON:
-	    case PROCESSOR_K8:
-	    case PROCESSOR_AMDFAM10:
-	    case PROCESSOR_BD:
-	    case PROCESSOR_ZNVER:
-	    case PROCESSOR_BT:
-	    case PROCESSOR_GENERIC32:
+	    default:
 	      /* We use cpu_arch_isa_flags to check if we CAN optimize
 		 with nops.  */
 	      if (fragP->tc_frag_data.isa_flags.bitfield.cpunop)
 		patt = alt_patt;
 	      break;
-	    case PROCESSOR_PENTIUMPRO:
-	    case PROCESSOR_PENTIUM4:
-	    case PROCESSOR_NOCONA:
-	    case PROCESSOR_CORE:
-	    case PROCESSOR_CORE2:
-	    case PROCESSOR_COREI7:
-	      if (fragP->tc_frag_data.isa_flags.bitfield.cpunop)
-		patt = alt_patt;
-	      break;
-	    case PROCESSOR_GENERIC64:
-	      patt = alt_patt;
-	      break;
+
 	    case PROCESSOR_NONE:
 	      abort ();
 	    }
--- a/gas/config/tc-i386.h
+++ b/gas/config/tc-i386.h
@@ -260,6 +260,7 @@ enum processor_type
   PROCESSOR_NONE
 };
 
+extern i386_cpu_flags cpu_arch_flags;
 extern enum processor_type cpu_arch_tune;
 extern enum processor_type cpu_arch_isa;
 extern i386_cpu_flags cpu_arch_isa_flags;
@@ -295,6 +296,7 @@ struct i386_tc_frag_data
   unsigned int mf_type : 3;
   unsigned int classified : 1;
   unsigned int branch_type : 3;
+  unsigned int cpunop : 1;
 };
 
 /* We need to emit the right NOP pattern in .align frags.  This is
@@ -310,6 +312,7 @@ struct i386_tc_frag_data
      (FRAGP)->tc_frag_data.isa = cpu_arch_isa;			\
      (FRAGP)->tc_frag_data.isa_flags = cpu_arch_isa_flags;	\
      (FRAGP)->tc_frag_data.tune = cpu_arch_tune;		\
+     (FRAGP)->tc_frag_data.cpunop = cpu_arch_flags.bitfield.cpunop; \
      (FRAGP)->tc_frag_data.code = i386_flag_code;		\
      (FRAGP)->tc_frag_data.max_bytes = (MAX_BYTES);		\
      (FRAGP)->tc_frag_data.length = 0;				\
--- a/gas/testsuite/gas/i386/x86-64.exp
+++ b/gas/testsuite/gas/i386/x86-64.exp
@@ -109,6 +109,8 @@ run_dump_test "x86-64-nops-1-g64"
 run_dump_test "x86-64-nops-1-k8"
 run_dump_test "x86-64-nops-1-core2"
 run_dump_test "x86-64-nops-1-pentium"
+run_dump_test "x86-64-nops-1a-g64"
+run_dump_test "x86-64-nops-1a-core2"
 run_dump_test "x86-64-nops-2"
 run_dump_test "x86-64-nops-3"
 run_dump_test "x86-64-nops-4"
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-nops-1a-core2.d
@@ -0,0 +1,5 @@
+#as: -march=core2+nonop
+#source: nops-1.s
+#objdump: -drw
+#name: x86-64 -march=core2+nonop nops 1
+#dump: x86-64-nops-1-pentium.d
--- /dev/null
+++ b/gas/testsuite/gas/i386/x86-64-nops-1a-g64.d
@@ -0,0 +1,5 @@
+#as: -march=generic64+nonop
+#source: nops-1.s
+#objdump: -drw
+#name: x86-64 -march=generic64+nonop nops 1
+#dump: x86-64-nops-1-pentium.d


  parent reply	other threads:[~2023-09-27 15:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-27 15:46 [PATCH 00/11] x86: NOP emission adjustments Jan Beulich
2023-09-27 15:47 ` [PATCH 01/11] x86: record flag_code in tc_frag_data Jan Beulich
2023-09-27 15:48 ` [PATCH 02/11] x86: i386_generate_nops() may not derive decisions from global variables Jan Beulich
2023-09-27 15:48 ` [PATCH 03/11] x86: don't use 32-bit LEA as NOP surrogate in 64-bit code Jan Beulich
2023-09-27 15:49 ` [PATCH 04/11] x86: don't use operand size override with NOP in 16-bit code Jan Beulich
2023-09-27 15:50 ` Jan Beulich [this message]
2023-09-27 15:50 ` [PATCH 06/11] x86: i686 != PentiumPro Jan Beulich
2023-09-27 15:51 ` [PATCH 07/11] x86: don't record full i386_cpu_flags in struct i386_tc_frag_data Jan Beulich
2023-09-27 15:51 ` [PATCH 08/11] x86: add a few more NOP patterns Jan Beulich
2023-09-27 15:52 ` [PATCH 09/11] x86: fold a few of the "alternative" " Jan Beulich
2023-09-27 15:52 ` [PATCH 10/11] x86: fold NOP testcase expectations where possible Jan Beulich
2023-09-27 15:53 ` [PATCH 11/11] gas: make .nops output visible in listing Jan Beulich
2023-09-27 15:59 ` [PATCH 00/11] x86: NOP emission adjustments Jan Beulich

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=a0856079-0bf9-20d7-bd62-8f5f20584251@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).