how to get -march=native's value?

how to get -march=native's value?

[unlvsur unlvsur]

I try to cross compile to another slower machine. -march=native works on that architectures, but I would like to know what is the value of -march=??? For -march=native. Is there a way to print march value out??

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

Re: how to get -march=native's value?

[Jonathan Wakely]

On Tue, 7 Sep 2021, 08:03 unlvsur unlvsur via Gcc-help, <
gcc-help@gcc.gnu.org> wrote:

> I try to cross compile to another slower machine. -march=native works on
> that architectures, but I would like to know what is the value of
> -march=??? For -march=native. Is there a way to print march value out??
>

It doesn't choose a single value. It enables all the individual options
like -msse and that combination of options might not correspond to any
particular -march value.

Re: how to get -march=native's value?

[Hongtao Liu]

On Tue, Sep 7, 2021 at 3:02 PM unlvsur unlvsur via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> I try to cross compile to another slower machine. -march=native works on that architectures, but I would like to know what is the value of -march=??? For -march=native. Is there a way to print march value out??
>
> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
>

add "-v" to the cmdline.
-- 
BR,
Hongtao

Re: how to get -march=native's value?

[NightStrike]

On Tue, Sep 7, 2021 at 3:57 AM Jonathan Wakely via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> On Tue, 7 Sep 2021, 08:03 unlvsur unlvsur via Gcc-help, <
> gcc-help@gcc.gnu.org> wrote:
>
> > I try to cross compile to another slower machine. -march=native works on
> > that architectures, but I would like to know what is the value of
> > -march=??? For -march=native. Is there a way to print march value out??
> >
>
> It doesn't choose a single value. It enables all the individual options
> like -msse and that combination of options might not correspond to any
> particular -march value.

Is that true?  I mean, in principle, I know I've reported a bug where
-march=native scanned /proc/cpuinfo (or however it got the info) and
came up with a different result than -march=k8 (or whatever I was
reporting at the time), but that was a bug that some helpful people
fixed.  If gcc doesn't have an -march for a particular esoteric arch,
then fine, but if it does, I'd think that this would be a bug similar
to what I experienced previously.

Re: how to get -march=native's value?

[Xi Ruoyao]

On Thu, 2021-09-16 at 22:46 -0400, NightStrike via Gcc-help wrote:
> On Tue, Sep 7, 2021 at 3:57 AM Jonathan Wakely via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
> > 
> > On Tue, 7 Sep 2021, 08:03 unlvsur unlvsur via Gcc-help, <
> > gcc-help@gcc.gnu.org> wrote:
> > 
> > > I try to cross compile to another slower machine. -march=native
> > > works on
> > > that architectures, but I would like to know what is the value of
> > > -march=??? For -march=native. Is there a way to print march value
> > > out??
> > > 
> > 
> > It doesn't choose a single value. It enables all the individual
> > options
> > like -msse and that combination of options might not correspond to any
> > particular -march value.
> 
> Is that true?  I mean, in principle, I know I've reported a bug where
> -march=native scanned /proc/cpuinfo (or however it got the info) and
> came up with a different result than -march=k8 (or whatever I was
> reporting at the time), but that was a bug that some helpful people
> fixed.  If gcc doesn't have an -march for a particular esoteric arch,
> then fine, but if it does, I'd think that this would be a bug similar
> to what I experienced previously.

It's documented clearly:

           native
               This selects the CPU to generate code for at compilation time
               by determining the processor type of the compiling machine.
               Using -march=native enables all instruction subsets supported
               by the local machine (hence the result might not run on
               different machines).  Using -mtune=native produces code
               optimized for the local machine under the constraints of the
               selected instruction set.

However if it produce something can't run on your machine,
this is a bug.
-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University

Re: how to get -march=native's value?

[Jonathan Wakely]

On Fri, 17 Sept 2021 at 09:29, Xi Ruoyao wrote:
>
> On Thu, 2021-09-16 at 22:46 -0400, NightStrike via Gcc-help wrote:
> > On Tue, Sep 7, 2021 at 3:57 AM Jonathan Wakely via Gcc-help
> > <gcc-help@gcc.gnu.org> wrote:
> > >
> > > On Tue, 7 Sep 2021, 08:03 unlvsur unlvsur via Gcc-help, <
> > > gcc-help@gcc.gnu.org> wrote:
> > >
> > > > I try to cross compile to another slower machine. -march=native
> > > > works on
> > > > that architectures, but I would like to know what is the value of
> > > > -march=??? For -march=native. Is there a way to print march value
> > > > out??
> > > >
> > >
> > > It doesn't choose a single value. It enables all the individual
> > > options
> > > like -msse and that combination of options might not correspond to any
> > > particular -march value.
> >
> > Is that true?  I mean, in principle, I know I've reported a bug where
> > -march=native scanned /proc/cpuinfo (or however it got the info) and
> > came up with a different result than -march=k8 (or whatever I was
> > reporting at the time), but that was a bug that some helpful people
> > fixed.  If gcc doesn't have an -march for a particular esoteric arch,
> > then fine, but if it does, I'd think that this would be a bug similar
> > to what I experienced previously.
>
> It's documented clearly:
>
>            native
>                This selects the CPU to generate code for at compilation time
>                by determining the processor type of the compiling machine.
>                Using -march=native enables all instruction subsets supported
>                by the local machine (hence the result might not run on
>                different machines).  Using -mtune=native produces code
>                optimized for the local machine under the constraints of the
>                selected instruction set.
>
> However if it produce something can't run on your machine,
> this is a bug.

Yes, but that's not what we're discussing.

The question is whether -march=native always corresponds to one of the
other -march=xxx options or not.

On my machine if I do -march=native the verbose asm shows:

-march=skylake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1
-msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mno-avx512f
-mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq
-mno-avx512cd -mno-avx512er -mno-avx512pf -mno-avx512vbmi
-mno-avx512ifma -mno-avx5124vnniw -mno-avx5124fmaps
-mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq
-mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16
-mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote
-mclflushopt -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c
-mfsgsbase -mfxsr -mhle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b
-mno-movdiri -mno-mwaitx -mno-pconfig -mno-pku -mno-prefetchwt1
-mprfchw -mno-ptwrite -mno-rdpid -mrdrnd -mrdseed -mrtm -mno-serialize
-msgx -mno-sha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes
-mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves
-mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset
-mno-kl -mno-widekl -mno-avxvnni -mno-avx512fp16
--param=l1-cache-size=32 --param=l1-cache-line-size=64
--param=l2-cache-size=8192 -mtune=skylake

So the question is whether that is any different to what is enabled by
just -march=skylake alone.The answer is yes, it's different. On my
machine -march=native adds -mabm and -mrtm which are not enabled by
-march=skylake, and it also uses different L1 and L2 cache sizes.
Compare:

$ diff <(g++ -march=skylake -Q --help=target --help=params) <(g++
-march=native -Q --help=target --help=params)
--- /dev/fd/63  2021-09-17 11:23:41.462736840 +0100
+++ /dev/fd/62  2021-09-17 11:23:41.463736847 +0100
@@ -9,7 +9,7 @@
  -m8bit-idiv                          [disabled]
  -m96bit-long-double                  [disabled]
  -mabi=                               sysv
-  -mabm                                [disabled]
+  -mabm                                [enabled]
  -maccumulate-outgoing-args           [disabled]
  -maddress-mode=                      long
  -madx                                [enabled]
@@ -149,7 +149,7 @@
  -mred-zone                           [enabled]
  -mregparm=                           6
  -mrtd                                [disabled]
-  -mrtm                                [disabled]
+  -mrtm                                [enabled]
  -msahf                               [enabled]
  -mserialize                          [disabled]
  -msgx                                [enabled]
@@ -328,8 +328,8 @@
  --param=jump-table-max-growth-ratio-for-size=        300
  --param=jump-table-max-growth-ratio-for-speed=       800
  --param=l1-cache-line-size=          64
-  --param=l1-cache-size=               64
-  --param=l2-cache-size=               512
+  --param=l1-cache-size=               32
+  --param=l2-cache-size=               8192
  --param=large-function-growth=       100
  --param=large-function-insns=        2700
  --param=large-stack-frame-growth=    1000

I get the same results for i7-8650U and i7-6700K.

Is that a bug in the -march=skylake settings? Maybe, I don't know. But
it shows that -march=native is not the same as just the named -march
option for my machines.

Re: how to get -march=native's value?

[Jonathan Wakely]

On Fri, 17 Sept 2021 at 11:26, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Fri, 17 Sept 2021 at 09:29, Xi Ruoyao wrote:
> >
> > On Thu, 2021-09-16 at 22:46 -0400, NightStrike via Gcc-help wrote:
> > > On Tue, Sep 7, 2021 at 3:57 AM Jonathan Wakely via Gcc-help
> > > <gcc-help@gcc.gnu.org> wrote:
> > > >
> > > > On Tue, 7 Sep 2021, 08:03 unlvsur unlvsur via Gcc-help, <
> > > > gcc-help@gcc.gnu.org> wrote:
> > > >
> > > > > I try to cross compile to another slower machine. -march=native
> > > > > works on
> > > > > that architectures, but I would like to know what is the value of
> > > > > -march=??? For -march=native. Is there a way to print march value
> > > > > out??
> > > > >
> > > >
> > > > It doesn't choose a single value. It enables all the individual
> > > > options
> > > > like -msse and that combination of options might not correspond to any
> > > > particular -march value.
> > >
> > > Is that true?  I mean, in principle, I know I've reported a bug where
> > > -march=native scanned /proc/cpuinfo (or however it got the info) and
> > > came up with a different result than -march=k8 (or whatever I was
> > > reporting at the time), but that was a bug that some helpful people
> > > fixed.  If gcc doesn't have an -march for a particular esoteric arch,
> > > then fine, but if it does, I'd think that this would be a bug similar
> > > to what I experienced previously.
> >
> > It's documented clearly:
> >
> >            native
> >                This selects the CPU to generate code for at compilation time
> >                by determining the processor type of the compiling machine.
> >                Using -march=native enables all instruction subsets supported
> >                by the local machine (hence the result might not run on
> >                different machines).  Using -mtune=native produces code
> >                optimized for the local machine under the constraints of the
> >                selected instruction set.
> >
> > However if it produce something can't run on your machine,
> > this is a bug.
>
> Yes, but that's not what we're discussing.
>
> The question is whether -march=native always corresponds to one of the
> other -march=xxx options or not.
>
> On my machine if I do -march=native the verbose asm shows:
>
> -march=skylake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1
> -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mno-avx512f
> -mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq
> -mno-avx512cd -mno-avx512er -mno-avx512pf -mno-avx512vbmi
> -mno-avx512ifma -mno-avx5124vnniw -mno-avx5124fmaps
> -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq
> -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16
> -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote
> -mclflushopt -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c
> -mfsgsbase -mfxsr -mhle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b
> -mno-movdiri -mno-mwaitx -mno-pconfig -mno-pku -mno-prefetchwt1
> -mprfchw -mno-ptwrite -mno-rdpid -mrdrnd -mrdseed -mrtm -mno-serialize
> -msgx -mno-sha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes
> -mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves
> -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset
> -mno-kl -mno-widekl -mno-avxvnni -mno-avx512fp16
> --param=l1-cache-size=32 --param=l1-cache-line-size=64
> --param=l2-cache-size=8192 -mtune=skylake
>
> So the question is whether that is any different to what is enabled by
> just -march=skylake alone.The answer is yes, it's different. On my
> machine -march=native adds -mabm and -mrtm which are not enabled by
> -march=skylake, and it also uses different L1 and L2 cache sizes.
> Compare:
>
> $ diff <(g++ -march=skylake -Q --help=target --help=params) <(g++
> -march=native -Q --help=target --help=params)
> --- /dev/fd/63  2021-09-17 11:23:41.462736840 +0100
> +++ /dev/fd/62  2021-09-17 11:23:41.463736847 +0100
> @@ -9,7 +9,7 @@
>   -m8bit-idiv                          [disabled]
>   -m96bit-long-double                  [disabled]
>   -mabi=                               sysv
> -  -mabm                                [disabled]
> +  -mabm                                [enabled]
>   -maccumulate-outgoing-args           [disabled]
>   -maddress-mode=                      long
>   -madx                                [enabled]
> @@ -149,7 +149,7 @@
>   -mred-zone                           [enabled]
>   -mregparm=                           6
>   -mrtd                                [disabled]
> -  -mrtm                                [disabled]
> +  -mrtm                                [enabled]
>   -msahf                               [enabled]
>   -mserialize                          [disabled]
>   -msgx                                [enabled]
> @@ -328,8 +328,8 @@
>   --param=jump-table-max-growth-ratio-for-size=        300
>   --param=jump-table-max-growth-ratio-for-speed=       800
>   --param=l1-cache-line-size=          64
> -  --param=l1-cache-size=               64
> -  --param=l2-cache-size=               512
> +  --param=l1-cache-size=               32
> +  --param=l2-cache-size=               8192
>   --param=large-function-growth=       100
>   --param=large-function-insns=        2700
>   --param=large-stack-frame-growth=    1000
>
> I get the same results for i7-8650U and i7-6700K.
>
> Is that a bug in the -march=skylake settings? Maybe, I don't know. But
> it shows that -march=native is not the same as just the named -march
> option for my machines.

And for a Xeon E5-2660, which GCC 11 identifies as sandybridge:

--- /dev/fd/63  2021-09-17 10:33:58.999696120 +0000
+++ /dev/fd/62  2021-09-17 10:33:59.000696129 +0000
@@ -13,7 +13,7 @@
  -maccumulate-outgoing-args           [disabled]
  -maddress-mode=                      long
  -madx                                [disabled]
-  -maes                                [disabled]
+  -maes                                [enabled]
  -malign-data=                        compat
  -malign-double                       [disabled]
  -malign-functions=                   0
@@ -326,8 +326,8 @@
  --param=jump-table-max-growth-ratio-for-size=        300
  --param=jump-table-max-growth-ratio-for-speed=       800
  --param=l1-cache-line-size=          64
-  --param=l1-cache-size=               64
-  --param=l2-cache-size=               512
+  --param=l1-cache-size=               32
+  --param=l2-cache-size=               20480
  --param=large-function-growth=       100
  --param=large-function-insns=        2700
  --param=large-stack-frame-growth=    1000

That -maes difference looks like a bug though, the manual says that
sandybridge should enable AES.

Re: how to get -march=native's value?

[Segher Boessenkool]

On Fri, Sep 17, 2021 at 11:26:16AM +0100, Jonathan Wakely via Gcc-help wrote:
> The question is whether -march=native always corresponds to one of the
> other -march=xxx options or not.

[ snip ]

> So the question is whether that is any different to what is enabled by
> just -march=skylake alone.The answer is yes, it's different. On my
> machine -march=native adds -mabm and -mrtm which are not enabled by
> -march=skylake, and it also uses different L1 and L2 cache sizes.

The cache sizes are -mtune=native, not -march=native.

> Is that a bug in the -march=skylake settings? Maybe, I don't know. But
> it shows that -march=native is not the same as just the named -march
> option for my machines.

For x86 -march=something is the same as -march=native, _if_ the compiler
knows about your CPU.  It will guess something reasonable otherwise.

This is all completely arch-specific (and OS-specific).  There are no
guarantees that you will get the same as any named CPU.  Your arch could
check for each feature if it can use it, as one extreme,

In the case of -mabm and -mrtm, it looks like the documentation could
use an update, perhaps.  The way this is structured the code and doc can
diverge easily.


Segher

Re: how to get -march=native's value?

[Vincent Lefevre]

On 2021-09-17 12:53:25 -0500, Segher Boessenkool wrote:
> For x86 -march=something is the same as -march=native, _if_ the compiler
> knows about your CPU.

It isn't:

cventin:~> diff -u <(gcc -Q --help=target --help=params -march=haswell) \
                   <(gcc -Q --help=target --help=params -march=native)
--- /proc/self/fd/11    2021-09-27 14:53:27.003263155 +0200
+++ /proc/self/fd/14    2021-09-27 14:53:27.003263155 +0200
@@ -9,11 +9,11 @@
   -m8bit-idiv                          [disabled]
   -m96bit-long-double                  [disabled]
   -mabi=                               sysv
-  -mabm                                [disabled]
+  -mabm                                [enabled]
   -maccumulate-outgoing-args           [disabled]
   -maddress-mode=                      long
   -madx                                [disabled]
-  -maes                                [disabled]
+  -maes                                [enabled]
   -malign-data=                        compat
   -malign-double                       [disabled]
   -malign-functions=                   0
@@ -304,8 +304,8 @@
   --param=jump-table-max-growth-ratio-for-size=        300
   --param=jump-table-max-growth-ratio-for-speed=       800
   --param=l1-cache-line-size=          64
-  --param=l1-cache-size=               64
-  --param=l2-cache-size=               512
+  --param=l1-cache-size=               32
+  --param=l2-cache-size=               15360
   --param=large-function-growth=       100
   --param=large-function-insns=        2700
   --param=large-stack-frame-growth=    1000

I don't understand "_if_ the compiler knows about your CPU": if the
compiler knows about the CPU, it should select more accurate options
(as shown above, where abm and aes get enabled), shouldn't it?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: how to get -march=native's value?

[Segher Boessenkool]

On Mon, Sep 27, 2021 at 02:55:28PM +0200, Vincent Lefevre wrote:
> On 2021-09-17 12:53:25 -0500, Segher Boessenkool wrote:
> > For x86 -march=something is the same as -march=native, _if_ the compiler
> > knows about your CPU.

> -  -mabm                                [disabled]
> +  -mabm                                [enabled]

So -mcpu=haswell disables ABM?  Huh.

I do not know the x86 backend very well, but that looks like a bug.

> -  -maes                                [disabled]
> +  -maes                                [enabled]

Here, too.  Esp. because the documentation says it 8should* be enabled.

Maybe some features are disabled on some Haswell though?

> -  --param=l1-cache-size=               64
> -  --param=l2-cache-size=               512
> +  --param=l1-cache-size=               32
> +  --param=l2-cache-size=               15360

This I already explained.


Segher

Re: how to get -march=native's value?

[L A Walsh]

On 2021/09/27 10:13, Segher Boessenkool wrote:
> On Mon, Sep 27, 2021 at 02:55:28PM +0200, Vincent Lefevre wrote:
>   
>> On 2021-09-17 12:53:25 -0500, Segher Boessenkool wrote:
>>     
>>> For x86 -march=something is the same as -march=native, _if_ the compiler
>>> knows about your CPU.
>>>       
----
I have a question, as someone reading this conversation ....

If one is using cross-compilation -- as it sounded like the original
author might be doing, what could the compiler know about the target
machine?

Is there some sort of "profile-this-cpu-for-pertinent-options" binary
or compiler-option that one should(or could) run on the target
machine in order that the correct compiler switches be set?

Otherwise, it would seem that -march=native would only be useful for
the (probably majority of) cases where one is compiling for their own
machine (?).

Re: how to get -march=native's value?

[Jonathan Wakely]

On Mon, 27 Sept 2021 at 19:16, L A Walsh <gcc@tlinx.org> wrote:
>
> On 2021/09/27 10:13, Segher Boessenkool wrote:
> > On Mon, Sep 27, 2021 at 02:55:28PM +0200, Vincent Lefevre wrote:
> >
> >> On 2021-09-17 12:53:25 -0500, Segher Boessenkool wrote:
> >>
> >>> For x86 -march=something is the same as -march=native, _if_ the compiler
> >>> knows about your CPU.
> >>>
> ----
> I have a question, as someone reading this conversation ....
>
> If one is using cross-compilation -- as it sounded like the original
> author might be doing, what could the compiler know about the target
> machine?

Only what you tell it.

> Is there some sort of "profile-this-cpu-for-pertinent-options" binary
> or compiler-option that one should(or could) run on the target
> machine in order that the correct compiler switches be set?
>
> Otherwise, it would seem that -march=native would only be useful for
> the (probably majority of) cases where one is compiling for their own
> machine (?).

Yes, -march=native is for native compilation, not cross compilation.
The clue is in the name :-)

Re: how to get -march=native's value?

[Florian Weimer]

* L. A. Walsh:

> Is there some sort of "profile-this-cpu-for-pertinent-options" binary
> or compiler-option that one should(or could) run on the target
> machine in order that the correct compiler switches be set?

In recent glibc, ld.so --help (the actual paths to ld.so vary
unfortunately) prints supported glibc-hwcaps subdirectories for some
common targets.  GCC supports a matching -march= or -mcpu= option (the
latter for POWER).  This does not cover all CPU features exactly, it is
a conservative approximation.  Cryptographic features and features with
a checkered past (features which already have been disabled once in a
microcode update) are left out.

Thanks,
Florian

Re: how to get -march=native's value?

[Segher Boessenkool]

On Mon, Sep 27, 2021 at 07:25:58PM +0100, Jonathan Wakely wrote:
> On Mon, 27 Sept 2021 at 19:16, L A Walsh <gcc@tlinx.org> wrote:
> > On 2021/09/27 10:13, Segher Boessenkool wrote:
> > > On Mon, Sep 27, 2021 at 02:55:28PM +0200, Vincent Lefevre wrote:
> > >> On 2021-09-17 12:53:25 -0500, Segher Boessenkool wrote:
> > >>
> > >>> For x86 -march=something is the same as -march=native, _if_ the compiler
> > >>> knows about your CPU.
> > >>>
> > ----
> > I have a question, as someone reading this conversation ....
> >
> > If one is using cross-compilation -- as it sounded like the original
> > author might be doing, what could the compiler know about the target
> > machine?
> 
> Only what you tell it.
> 
> > Is there some sort of "profile-this-cpu-for-pertinent-options" binary
> > or compiler-option that one should(or could) run on the target
> > machine in order that the correct compiler switches be set?
> >
> > Otherwise, it would seem that -march=native would only be useful for
> > the (probably majority of) cases where one is compiling for their own
> > machine (?).
> 
> Yes, -march=native is for native compilation, not cross compilation.
> The clue is in the name :-)

And in fact you get something like

$ x86_64-linux-gcc-12.0.0 -Wall -W -O2 -S at.c -march=native
cc1: error: bad value ('native') for '-march=' switch
cc1: note: valid arguments to '-march=' switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client rocketlake icelake-server cascadelake tigerlake cooperlake sapphirerapids alderlake bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm x86-64 x86-64-v2 x86-64-v3 x86-64-v4 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 znver3 btver1 btver2

when you try.  Not the friendliest error message perhaps, but it is a
pretty silly thing to try as well :-)  (This has been the same since at
least 5.4.1 (but the note is newer)).


Segher

Re: how to get -march=native's value?

[NightStrike]

On Mon, Sep 27, 2021 at 4:28 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Mon, Sep 27, 2021 at 07:25:58PM +0100, Jonathan Wakely wrote:
> > On Mon, 27 Sept 2021 at 19:16, L A Walsh <gcc@tlinx.org> wrote:
> > > On 2021/09/27 10:13, Segher Boessenkool wrote:
> > > > On Mon, Sep 27, 2021 at 02:55:28PM +0200, Vincent Lefevre wrote:
> > > >> On 2021-09-17 12:53:25 -0500, Segher Boessenkool wrote:
> > > >>
> > > >>> For x86 -march=something is the same as -march=native, _if_ the compiler
> > > >>> knows about your CPU.
> > > >>>
> > > ----
> > > I have a question, as someone reading this conversation ....
> > >
> > > If one is using cross-compilation -- as it sounded like the original
> > > author might be doing, what could the compiler know about the target
> > > machine?
> >
> > Only what you tell it.
> >
> > > Is there some sort of "profile-this-cpu-for-pertinent-options" binary
> > > or compiler-option that one should(or could) run on the target
> > > machine in order that the correct compiler switches be set?
> > >
> > > Otherwise, it would seem that -march=native would only be useful for
> > > the (probably majority of) cases where one is compiling for their own
> > > machine (?).
> >
> > Yes, -march=native is for native compilation, not cross compilation.
> > The clue is in the name :-)
>
> And in fact you get something like
>
> $ x86_64-linux-gcc-12.0.0 -Wall -W -O2 -S at.c -march=native
> cc1: error: bad value ('native') for '-march=' switch
> cc1: note: valid arguments to '-march=' switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client rocketlake icelake-server cascadelake tigerlake cooperlake sapphirerapids alderlake bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm x86-64 x86-64-v2 x86-64-v3 x86-64-v4 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 znver3 btver1 btver2
>
> when you try.  Not the friendliest error message perhaps, but it is a
> pretty silly thing to try as well :-)  (This has been the same since at
> least 5.4.1 (but the note is newer)).

There are cases where that's a reasonable thing to do, for instance
when running a mingw-w64 cross compiler on cygwin.  Anytime the host
computer can run a target binary, then native makes sense.  There is
probably a Linux / Wine use case, too.