public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: <apinski@marvell.com>
To: <gcc-patches@gcc.gnu.org>
Cc: Andrew Pinski <apinski@marvell.com>
Subject: [PATCH] Remove SLOW_SHORT_ACCESS from target headers
Date: Wed, 9 Nov 2022 17:15:34 -0800	[thread overview]
Message-ID: <1668042934-1377-1-git-send-email-apinski@marvell.com> (raw)

From: Andrew Pinski <apinski@marvell.com>

SLOW_SHORT_ACCESS is defined in bfin and i386 target
headers but the target macro is not used elsewhere.
So let's remove it from those two headers and posion it.

OK? Built x86_64-linux-gnu and bfin-elf.

gcc/ChangeLog:

	* config/bfin/bfin.h (SLOW_SHORT_ACCESS): Delete.
	* config/i386/i386.h (SLOW_SHORT_ACCESS): Delete.
	* system.h: Poison SLOW_SHORT_ACCESS
---
 gcc/config/bfin/bfin.h | 1 -
 gcc/config/i386/i386.h | 3 ---
 gcc/system.h           | 2 +-
 3 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/gcc/config/bfin/bfin.h b/gcc/config/bfin/bfin.h
index 4e7753038a8..1d75c655df8 100644
--- a/gcc/config/bfin/bfin.h
+++ b/gcc/config/bfin/bfin.h
@@ -810,7 +810,6 @@ typedef struct {
    subsequent accesses occur to other fields in the same word of the
    structure, but to different bytes.  */
 #define SLOW_BYTE_ACCESS  0
-#define SLOW_SHORT_ACCESS 0
 
 /* Define this if most significant bit is lowest numbered
    in instructions that operate on numbered bit-fields. */
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index b32db8da109..a5ad9f387f7 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -1933,9 +1933,6 @@ do {							\
 
 #define SLOW_BYTE_ACCESS 0
 
-/* Nonzero if access to memory by shorts is slow and undesirable.  */
-#define SLOW_SHORT_ACCESS 0
-
 /* Define this macro if it is as good or better to call a constant
    function address than to call an address kept in a register.
 
diff --git a/gcc/system.h b/gcc/system.h
index c192b6c3ce7..de9c5c0d2ef 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -1075,7 +1075,7 @@ extern void fancy_abort (const char *, int, const char *)
 	EH_FRAME_IN_DATA_SECTION TARGET_FLT_EVAL_METHOD_NON_DEFAULT	   \
 	JCR_SECTION_NAME TARGET_USE_JCR_SECTION SDB_DEBUGGING_INFO	   \
 	SDB_DEBUG NO_IMPLICIT_EXTERN_C NOTICE_UPDATE_CC			   \
-	CC_STATUS_MDEP_INIT CC_STATUS_MDEP CC_STATUS
+	CC_STATUS_MDEP_INIT CC_STATUS_MDEP CC_STATUS SLOW_SHORT_ACCESS
 
 /* Hooks that are no longer used.  */
  #pragma GCC poison LANG_HOOKS_FUNCTION_MARK LANG_HOOKS_FUNCTION_FREE	\
-- 
2.17.1


             reply	other threads:[~2022-11-10  1:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-10  1:15 apinski [this message]
2022-11-10  1:20 ` Andrew Pinski
2022-11-10  8:47   ` Richard Biener
2022-11-10 16:22     ` Andrew Pinski

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=1668042934-1377-1-git-send-email-apinski@marvell.com \
    --to=apinski@marvell.com \
    --cc=gcc-patches@gcc.gnu.org \
    /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).