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 09/11] x86: fold a few of the "alternative" NOP patterns
Date: Wed, 27 Sep 2023 17:52:08 +0200	[thread overview]
Message-ID: <b5e9a399-ea6c-5dd1-d7b0-79a01083d607@suse.com> (raw)
In-Reply-To: <7ce54bc2-fef2-d2e4-21fd-202fdead0c20@suse.com>

Since named objects may not overlap, the compiler is not permitted to do
this for us, to avoid wasting space and cache bandwidth/capacity.

--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1324,8 +1324,7 @@ static const unsigned char alt_3[] =
 static const unsigned char alt_4[] =
   {0x0f,0x1f,0x40,0x00};
 /* nopl 0(%[re]ax,%[re]ax,1) */
-static const unsigned char alt_5[] =
-  {0x0f,0x1f,0x44,0x00,0x00};
+#define alt_5 (alt_6 + 1)
 /* nopw 0(%[re]ax,%[re]ax,1) */
 static const unsigned char alt_6[] =
   {0x66,0x0f,0x1f,0x44,0x00,0x00};
@@ -1333,14 +1332,12 @@ static const unsigned char alt_6[] =
 static const unsigned char alt_7[] =
   {0x0f,0x1f,0x80,0x00,0x00,0x00,0x00};
 /* nopl 0L(%[re]ax,%[re]ax,1) */
-static const unsigned char alt_8[] =
-  {0x0f,0x1f,0x84,0x00,0x00,0x00,0x00,0x00};
+#define alt_8 (alt_9 + 1)
 /* nopw 0L(%[re]ax,%[re]ax,1) */
 static const unsigned char alt_9[] =
   {0x66,0x0f,0x1f,0x84,0x00,0x00,0x00,0x00,0x00};
 /* nopw %cs:0L(%[re]ax,%[re]ax,1) */
-static const unsigned char alt_10[] =
-  {0x66,0x2e,0x0f,0x1f,0x84,0x00,0x00,0x00,0x00,0x00};
+#define alt_10 (alt_11 + 1)
 /* data16 nopw %cs:0L(%eax,%eax,1) */
 static const unsigned char alt_11[] =
   {0x66,0x66,0x2e,0x0f,0x1f,0x84,0x00,0x00,0x00,0x00,0x00};


  parent reply	other threads:[~2023-09-27 15:52 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 ` [PATCH 05/11] x86: respect ".arch nonop" when selecting which NOPs to emit Jan Beulich
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 ` Jan Beulich [this message]
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=b5e9a399-ea6c-5dd1-d7b0-79a01083d607@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).