public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Kyrylo Tkachov <ktkachov@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r13-2757] aarch64: Rewrite -march=native to -mcpu if no other -mcpu or -mtune is given
Date: Wed, 21 Sep 2022 09:11:44 +0000 (GMT)	[thread overview]
Message-ID: <20220921091144.992243858D37@sourceware.org> (raw)

https://gcc.gnu.org/g:dd9e5f4db2debf1429feab7f785962ccef6e0dbd

commit r13-2757-gdd9e5f4db2debf1429feab7f785962ccef6e0dbd
Author: Kyrylo Tkachov <kyrylo.tkachov@arm.com>
Date:   Wed Sep 21 10:10:21 2022 +0100

    aarch64: Rewrite -march=native to -mcpu if no other -mcpu or -mtune is given
    
    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.
    
    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".

Diff:
---
 gcc/config/aarch64/aarch64.h | 50 ++++++++++++++++++++++++++++----------------
 1 file changed, 32 insertions(+), 18 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 2eed6e8f6f0..6f6bb70fde9 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:11 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=20220921091144.992243858D37@sourceware.org \
    --to=ktkachov@gcc.gnu.org \
    --cc=gcc-cvs@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).