public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug jit/66594] New: jitted code should use -mtune=native
@ 2015-06-19  1:28 dmalcolm at gcc dot gnu.org
  2015-06-19  1:39 ` [Bug jit/66594] " pinskia at gcc dot gnu.org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2015-06-19  1:28 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594

            Bug ID: 66594
           Summary: jitted code should use -mtune=native
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: jit
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

We should probably default to -mtune=native when building code in-memory (but
probably to -mtune=generic when compiling to disk?).  Perhaps an option, or
maybe expose these options directly?

Note to self:

  * I see in gcc.c:
      /* As special support for cross compilers we read -mtune=native
             as -mtune=generic.  With native compilers we won't see the
             -mtune=native, as it was changed by the driver.  */
      if (!strcmp (opts->x_ix86_tune_string, "native"))
        {
          opts->x_ix86_tune_string = "generic";
        } 

hence we need to somehow run the *driver* logic for -mtune=native.

Note that that logic can be a no-op under non-bootstrapped builds; see bug
66593.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug jit/66594] jitted code should use -mtune=native
  2015-06-19  1:28 [Bug jit/66594] New: jitted code should use -mtune=native dmalcolm at gcc dot gnu.org
@ 2015-06-19  1:39 ` pinskia at gcc dot gnu.org
  2015-06-19 16:20 ` dmalcolm at gcc dot gnu.org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2015-06-19  1:39 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This should be true on all targets which have -mcpu=native (or -march=native). 
Note x86 options are not always the same on x86 vs arm vs aarch64 vs ppc.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug jit/66594] jitted code should use -mtune=native
  2015-06-19  1:28 [Bug jit/66594] New: jitted code should use -mtune=native dmalcolm at gcc dot gnu.org
  2015-06-19  1:39 ` [Bug jit/66594] " pinskia at gcc dot gnu.org
@ 2015-06-19 16:20 ` dmalcolm at gcc dot gnu.org
  2015-06-19 16:21 ` dmalcolm at gcc dot gnu.org
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2015-06-19 16:20 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594

--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> This should be true on all targets which have -mcpu=native (or
> -march=native).  Note x86 options are not always the same on x86 vs arm vs
> aarch64 vs ppc.

Thanks.

Is there a way to express
  "give me the most specialized possible code for the current host"?
in a manner that's consistent across all supported hosts?
(e.g. in the "specs" language?)

e.g. "-march=native -mcpu=native -mtune=native"


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug jit/66594] jitted code should use -mtune=native
  2015-06-19  1:28 [Bug jit/66594] New: jitted code should use -mtune=native dmalcolm at gcc dot gnu.org
  2015-06-19  1:39 ` [Bug jit/66594] " pinskia at gcc dot gnu.org
  2015-06-19 16:20 ` dmalcolm at gcc dot gnu.org
@ 2015-06-19 16:21 ` dmalcolm at gcc dot gnu.org
  2015-06-19 16:30 ` ktkachov at gcc dot gnu.org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2015-06-19 16:21 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594

--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Some notes:

The following archs seem to implement a "host_detect_local_cpu" C++ callback,
implementing the spec-language function "local_cpu_detect":

grep -nH -e host_detect_local_cpu */*/*.h
config/aarch64/aarch64.h:944:extern const char *host_detect_local_cpu (int
argc, const char **argv);
config/aarch64/aarch64.h:946:  { "local_cpu_detect", host_detect_local_cpu },  
                \
config/alpha/linux.h:95:extern const char *host_detect_local_cpu (int argc,
const char **argv);
config/alpha/linux.h:97:  { "local_cpu_detect", host_detect_local_cpu },
config/arm/arm.h:2246:extern const char *host_detect_local_cpu (int argc, const
char **argv);
config/arm/arm.h:2248:  { "local_cpu_detect", host_detect_local_cpu },         
        \
config/i386/i386.h:604:extern const char *host_detect_local_cpu (int argc,
const char **argv);
config/i386/i386.h:606:  { "local_cpu_detect", host_detect_local_cpu },
config/mips/gnu-user.h:111:extern const char *host_detect_local_cpu (int argc,
const char **argv);
config/mips/gnu-user.h:113:  { "local_cpu_detect", host_detect_local_cpu },
config/rs6000/rs6000.h:204:extern const char *host_detect_local_cpu (int argc,
const char **argv);
config/rs6000/rs6000.h:206:  { "local_cpu_detect", host_detect_local_cpu },
config/s390/s390.h:129:extern const char *s390_host_detect_local_cpu (int argc,
const char **argv);
config/s390/s390.h:131:  { "local_cpu_detect", s390_host_detect_local_cpu },
config/sparc/linux64.h:133:extern const char *host_detect_local_cpu (int argc,
const char **argv);
config/sparc/linux64.h:135:  { "local_cpu_detect", host_detect_local_cpu },
config/sparc/linux.h:44:extern const char *host_detect_local_cpu (int argc,
const char **argv);
config/sparc/linux.h:46:  { "local_cpu_detect", host_detect_local_cpu },
config/sparc/sol2.h:203:extern const char *host_detect_local_cpu (int argc,
const char **argv);
config/sparc/sol2.h:205:  { "local_cpu_detect", host_detect_local_cpu },


aarch64.h has:
# 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)}"


alpha/linux.h has:
# define MCPU_MTUNE_NATIVE_SPECS                                        \
   " %{mcpu=native:%<mcpu=native %:local_cpu_detect(cpu)}"              \
   " %{mtune=native:%<mtune=native %:local_cpu_detect(tune)}"


arm.h has:
# 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)}"


i386.h has:
#ifndef HAVE_LOCAL_CPU_DETECT
#define CC1_CPU_SPEC CC1_CPU_SPEC_1
#else
#define CC1_CPU_SPEC CC1_CPU_SPEC_1 \
"%{march=native:%>march=native %:local_cpu_detect(arch) \
  %{!mtune=*:%>mtune=native %:local_cpu_detect(tune)}} \
%{mtune=native:%>mtune=native %:local_cpu_detect(tune)}"
#endif
#endif


mips/gnu-user.h has:
# define MARCH_MTUNE_NATIVE_SPECS                               \
  " %{march=native:%<march=native %:local_cpu_detect(arch)}"    \
  " %{mtune=native:%<mtune=native %:local_cpu_detect(tune)}"

#define HAVE_LOCAL_CPU_DETECT
#define ASM_CPU_NATIVE_SPEC "%:local_cpu_detect(asm)"

#else
#define ASM_CPU_NATIVE_SPEC "%(asm_default)"
#endif


rs6000.h has:
#ifndef CC1_CPU_SPEC
#ifdef HAVE_LOCAL_CPU_DETECT
#define CC1_CPU_SPEC \
"%{mcpu=native:%<mcpu=native %:local_cpu_detect(cpu)} \
 %{mtune=native:%<mtune=native %:local_cpu_detect(tune)}"
#else
#define CC1_CPU_SPEC ""
#endif
#endif


s390.h has:
# define MARCH_MTUNE_NATIVE_SPECS                               \
  " %{march=native:%<march=native %:local_cpu_detect(arch)}"    \
  " %{mtune=native:%<mtune=native %:local_cpu_detect(tune)}"


sparc/linux64.h, sparc/linux.h and sparc/sol2.h have:
# define MCPU_MTUNE_NATIVE_SPECS                                        \
   " %{mcpu=native:%<mcpu=native %:local_cpu_detect(cpu)}"              \
   " %{mtune=native:%<mtune=native %:local_cpu_detect(tune)}"


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug jit/66594] jitted code should use -mtune=native
  2015-06-19  1:28 [Bug jit/66594] New: jitted code should use -mtune=native dmalcolm at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2015-06-19 16:21 ` dmalcolm at gcc dot gnu.org
@ 2015-06-19 16:30 ` ktkachov at gcc dot gnu.org
  2015-06-19 17:12 ` dmalcolm at gcc dot gnu.org
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: ktkachov at gcc dot gnu.org @ 2015-06-19 16:30 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594

--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to David Malcolm from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > This should be true on all targets which have -mcpu=native (or
> > -march=native).  Note x86 options are not always the same on x86 vs arm vs
> > aarch64 vs ppc.
> 
> Thanks.
> 
> Is there a way to express
>   "give me the most specialized possible code for the current host"?
> in a manner that's consistent across all supported hosts?
> (e.g. in the "specs" language?)
> 
> e.g. "-march=native -mcpu=native -mtune=native"

A note that the meaning of march/mcpu/mtune may differ among targets.
For arm and aarch64, for example, the preferred option is -mcpu, which is the
combination of march+mtune


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug jit/66594] jitted code should use -mtune=native
  2015-06-19  1:28 [Bug jit/66594] New: jitted code should use -mtune=native dmalcolm at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2015-06-19 16:30 ` ktkachov at gcc dot gnu.org
@ 2015-06-19 17:12 ` dmalcolm at gcc dot gnu.org
  2015-06-19 17:15 ` dmalcolm at gcc dot gnu.org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2015-06-19 17:12 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594

--- Comment #5 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Created attachment 35815
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35815&action=edit
Hacky work-in-progress fix, using hardcoded calls to host_detect_local_cpu

The attached patch is a hack, in that 
 (A) it assumes host_detect_local_cpu exists, which isn't always the case, 
 (B) it loops through "arch", "cpu", "tune", trying all of them, and appending
any results in order to libgccjit's fake args.

...but it seems to work on x86_64.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug jit/66594] jitted code should use -mtune=native
  2015-06-19  1:28 [Bug jit/66594] New: jitted code should use -mtune=native dmalcolm at gcc dot gnu.org
                   ` (4 preceding siblings ...)
  2015-06-19 17:12 ` dmalcolm at gcc dot gnu.org
@ 2015-06-19 17:15 ` dmalcolm at gcc dot gnu.org
  2023-05-19  1:25 ` pinskia at gcc dot gnu.org
  2023-05-24 18:13 ` schuchart at icl dot utk.edu
  7 siblings, 0 replies; 9+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2015-06-19 17:15 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594

--- Comment #6 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to ktkachov from comment #4)
> (In reply to David Malcolm from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > This should be true on all targets which have -mcpu=native (or
> > > -march=native).  Note x86 options are not always the same on x86 vs arm vs
> > > aarch64 vs ppc.
> > 
> > Thanks.
> > 
> > Is there a way to express
> >   "give me the most specialized possible code for the current host"?
> > in a manner that's consistent across all supported hosts?
> > (e.g. in the "specs" language?)
> > 
> > e.g. "-march=native -mcpu=native -mtune=native"
> 
> A note that the meaning of march/mcpu/mtune may differ among targets.
> For arm and aarch64, for example, the preferred option is -mcpu, which is
> the combination of march+mtune

Perhaps we need a target macro that's something like:
  TARGET_JIT_NATIVE_CODE_SPEC
or somesuch, defaulting to empty, but defining it per-arch to a spec-language
string containing the appropriate option(s) for that host/target?  (assuming
host==target, which is currently the case for the jit).


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug jit/66594] jitted code should use -mtune=native
  2015-06-19  1:28 [Bug jit/66594] New: jitted code should use -mtune=native dmalcolm at gcc dot gnu.org
                   ` (5 preceding siblings ...)
  2015-06-19 17:15 ` dmalcolm at gcc dot gnu.org
@ 2023-05-19  1:25 ` pinskia at gcc dot gnu.org
  2023-05-24 18:13 ` schuchart at icl dot utk.edu
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-05-19  1:25 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |helohe at bluewin dot ch

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 107230 has been marked as a duplicate of this bug. ***

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug jit/66594] jitted code should use -mtune=native
  2015-06-19  1:28 [Bug jit/66594] New: jitted code should use -mtune=native dmalcolm at gcc dot gnu.org
                   ` (6 preceding siblings ...)
  2023-05-19  1:25 ` pinskia at gcc dot gnu.org
@ 2023-05-24 18:13 ` schuchart at icl dot utk.edu
  7 siblings, 0 replies; 9+ messages in thread
From: schuchart at icl dot utk.edu @ 2023-05-24 18:13 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594

Joseph <schuchart at icl dot utk.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schuchart at icl dot utk.edu

--- Comment #10 from Joseph <schuchart at icl dot utk.edu> ---
The lack of target-specific optimizations is biting us quite a bit and manually
specifying an architecture is not really an option, unless we duplicate the
detection mechanism of GCC, which is not ideal. I am not familiar with the GCC
code base and from the discussion below it's not clear what would be needed to
advance this. If someone could provide some hints on what is missing and
how/where it could be implemented we could probably take a stab at it. 

Would it be sufficient to add a macro to the header of the targets (as
suggested here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594#c6) that
provide host_detect_local_cpu and ignore the ones that do not provide it? Or
would it be better to hard-code calls for the architectures that provide them,
like in the referenced patch but with architecture-specific pre-processor
guards? We mostly care about i386 and arm/aarch64 but covering all available
bases would be necessary, I guess.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2023-05-24 18:13 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-19  1:28 [Bug jit/66594] New: jitted code should use -mtune=native dmalcolm at gcc dot gnu.org
2015-06-19  1:39 ` [Bug jit/66594] " pinskia at gcc dot gnu.org
2015-06-19 16:20 ` dmalcolm at gcc dot gnu.org
2015-06-19 16:21 ` dmalcolm at gcc dot gnu.org
2015-06-19 16:30 ` ktkachov at gcc dot gnu.org
2015-06-19 17:12 ` dmalcolm at gcc dot gnu.org
2015-06-19 17:15 ` dmalcolm at gcc dot gnu.org
2023-05-19  1:25 ` pinskia at gcc dot gnu.org
2023-05-24 18:13 ` schuchart at icl dot utk.edu

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).