public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>
To: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: [PATCH] aarch64: Rewrite -march=native to -mcpu if no other -mcpu or -mtune is given
Date: Wed, 21 Sep 2022 09:08:28 +0000	[thread overview]
Message-ID: <PAXPR08MB69268E54FB0740944699A950934F9@PAXPR08MB6926.eurprd08.prod.outlook.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2178 bytes --]

Hi all,

We have received requests to improve the out-of-the box experience and
performance of AArch64 GCC users, particularly those porting software from other
architectures. This has many aspects. One such aspect are apps built natively
with an -march=native used as a tuning flag in the Makefile.
On AArch64 this selects the right architecture features on GNU+Linux for the
host system but tunes for the "generic" CPU target.
This patch makes GCC also tune for the host CPU, as well as selecting its
architecture. That is, it translates -march=native into -mcpu=native.
This maintains the documentation that it "causes the compiler to pick the
architecture of the host system" since -mcpu=native does that, but it also
gives a better performance experience for the user.

If the user explicitly asked for a particular CPU tuning through -mcpu or
-mtune then we don't do this rewriting so that the user option is honoured.

This would have been a one-line patch if it wasn't for --with-tune
configure-time arguments. When GCC is configured with --with-tune=<CORE> the
OPTION_DEFAULT_SPECS will insert an -mtune=<CORE> in the options if no other
-mcpu or -mtune options were given. This will spook the aforementioned desired
rewriting of -march=native into -mcpu=native, though I'd argue that we want to
do the rewrite even then. Therefore, this patch moves some specs in aarch64.h
around and refactors the --with-tune rewriting into CONFIG_TUNE_SPEC so that
the materialization of the implicit -mtune=<CORE> does not happen if -march=native
is used.

Bootstrapped and tested on aarch64-none-linux-gnu and checked with the output
of -### from the driver that the option rewriting works as expected on
aarch64-linux-gnu.

Pushing to trunk.
Thanks,
Kyrill

gcc/ChangeLog:

	* config/aarch64/aarch64.h (HAVE_LOCAL_CPU_DETECT,
	EXTRA_SPEC_FUNCTIONS, MCPU_MTUNE_NATIVE_SPECS): Move definitions up before
	OPTION_DEFAULT_SPECS.
	(MCPU_MTUNE_NATIVE_SPECS): Pass "cpu" to
	local_cpu_detect when rewriting -march=native and no -mcpu or -mtune
	is given.
	(CONFIG_TUNE_SPEC): Define.
	(OPTION_DEFAULT_SPECS): Use CONFIG_TUNE_SPEC for "tune".

[-- Attachment #2: march-mcpu.patch --]
[-- Type: application/octet-stream, Size: 3413 bytes --]

diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 2eed6e8f6f05e748372257ff89d338d3777ddbbb..6f6bb70fde955f6664e7cd48236ef79d0ee330d5 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -1260,14 +1260,44 @@ extern enum aarch64_code_model aarch64_cmodel;
 #define ENDIAN_LANE_N(NUNITS, N) \
   (BYTES_BIG_ENDIAN ? NUNITS - 1 - N : N)
 
+/* Extra specs when building a native AArch64-hosted compiler.
+   Option rewriting rules based on host system.  */
+#if defined(__aarch64__)
+extern const char *host_detect_local_cpu (int argc, const char **argv);
+#define HAVE_LOCAL_CPU_DETECT
+# define EXTRA_SPEC_FUNCTIONS                                           \
+  { "local_cpu_detect", host_detect_local_cpu },                        \
+  MCPU_TO_MARCH_SPEC_FUNCTIONS
+
+/* Rewrite -m{arch,cpu,tune}=native based on the host system information.
+   When rewriting -march=native convert it into an -mcpu option if no other
+   -mcpu or -mtune was given.  */
+# define MCPU_MTUNE_NATIVE_SPECS                                        \
+   " %{march=native:%<march=native %:local_cpu_detect(%{mcpu=*|mtune=*:arch;:cpu})}"            \
+   " %{mcpu=native:%<mcpu=native %:local_cpu_detect(cpu)}"              \
+   " %{mtune=native:%<mtune=native %:local_cpu_detect(tune)}"
+/* This will be used in OPTION_DEFAULT_SPECS below.
+   When GCC is configured with --with-tune we don't want to materialize an
+   implicit -mtune would prevent the rewriting of -march=native into
+   -mcpu=native as per the above rules.  */
+#define CONFIG_TUNE_SPEC						\
+ { "tune", "%{!mcpu=*:%{!mtune=*:%{!march=native:-mtune=%(VALUE)}}}" },
+#else
+# define MCPU_MTUNE_NATIVE_SPECS ""
+# define EXTRA_SPEC_FUNCTIONS MCPU_TO_MARCH_SPEC_FUNCTIONS
+# define CONFIG_TUNE_SPEC                                                \
+  {"tune", "%{!mcpu=*:%{!mtune=*:-mtune=%(VALUE)}}"},
+#endif
+
 /* Support for configure-time --with-arch, --with-cpu and --with-tune.
    --with-arch and --with-cpu are ignored if either -mcpu or -march is used.
    --with-tune is ignored if either -mtune or -mcpu is used (but is not
-   affected by -march).  */
+   affected by -march, except in the -march=native case as per the
+   CONFIG_TUNE_SPEC above).  */
 #define OPTION_DEFAULT_SPECS				\
   {"arch", "%{!march=*:%{!mcpu=*:-march=%(VALUE)}}" },	\
   {"cpu",  "%{!march=*:%{!mcpu=*:-mcpu=%(VALUE)}}" },   \
-  {"tune", "%{!mcpu=*:%{!mtune=*:-mtune=%(VALUE)}}"},
+  CONFIG_TUNE_SPEC
 
 #define MCPU_TO_MARCH_SPEC \
    " %{mcpu=*:-march=%:rewrite_mcpu(%{mcpu=*:%*})}"
@@ -1276,22 +1306,6 @@ extern const char *aarch64_rewrite_mcpu (int argc, const char **argv);
 #define MCPU_TO_MARCH_SPEC_FUNCTIONS \
   { "rewrite_mcpu", aarch64_rewrite_mcpu },
 
-#if defined(__aarch64__)
-extern const char *host_detect_local_cpu (int argc, const char **argv);
-#define HAVE_LOCAL_CPU_DETECT
-# define EXTRA_SPEC_FUNCTIONS						\
-  { "local_cpu_detect", host_detect_local_cpu },			\
-  MCPU_TO_MARCH_SPEC_FUNCTIONS
-
-# define MCPU_MTUNE_NATIVE_SPECS					\
-   " %{march=native:%<march=native %:local_cpu_detect(arch)}"		\
-   " %{mcpu=native:%<mcpu=native %:local_cpu_detect(cpu)}"		\
-   " %{mtune=native:%<mtune=native %:local_cpu_detect(tune)}"
-#else
-# define MCPU_MTUNE_NATIVE_SPECS ""
-# define EXTRA_SPEC_FUNCTIONS MCPU_TO_MARCH_SPEC_FUNCTIONS
-#endif
-
 #define ASM_CPU_SPEC \
    MCPU_TO_MARCH_SPEC
 

                 reply	other threads:[~2022-09-21  9:08 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=PAXPR08MB69268E54FB0740944699A950934F9@PAXPR08MB6926.eurprd08.prod.outlook.com \
    --to=kyrylo.tkachov@arm.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).