* how to get -march=native's value? @ 2021-09-07 7:02 unlvsur unlvsur 2021-09-07 7:56 ` Jonathan Wakely 2021-09-07 7:59 ` Hongtao Liu 0 siblings, 2 replies; 15+ messages in thread From: unlvsur unlvsur @ 2021-09-07 7:02 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: how to get -march=native's value? 2021-09-07 7:02 how to get -march=native's value? unlvsur unlvsur @ 2021-09-07 7:56 ` Jonathan Wakely 2021-09-17 2:46 ` NightStrike 2021-09-07 7:59 ` Hongtao Liu 1 sibling, 1 reply; 15+ messages in thread From: Jonathan Wakely @ 2021-09-07 7:56 UTC (permalink / raw) To: unlvsur unlvsur; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: how to get -march=native's value? 2021-09-07 7:56 ` Jonathan Wakely @ 2021-09-17 2:46 ` NightStrike 2021-09-17 8:29 ` Xi Ruoyao 0 siblings, 1 reply; 15+ messages in thread From: NightStrike @ 2021-09-17 2:46 UTC (permalink / raw) To: Jonathan Wakely; +Cc: unlvsur unlvsur, gcc-help 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: how to get -march=native's value? 2021-09-17 2:46 ` NightStrike @ 2021-09-17 8:29 ` Xi Ruoyao 2021-09-17 10:26 ` Jonathan Wakely 0 siblings, 1 reply; 15+ messages in thread From: Xi Ruoyao @ 2021-09-17 8:29 UTC (permalink / raw) To: NightStrike, Jonathan Wakely; +Cc: gcc-help, unlvsur unlvsur 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: how to get -march=native's value? 2021-09-17 8:29 ` Xi Ruoyao @ 2021-09-17 10:26 ` Jonathan Wakely 2021-09-17 10:38 ` Jonathan Wakely 2021-09-17 17:53 ` Segher Boessenkool 0 siblings, 2 replies; 15+ messages in thread From: Jonathan Wakely @ 2021-09-17 10:26 UTC (permalink / raw) To: Xi Ruoyao; +Cc: NightStrike, gcc-help, unlvsur unlvsur 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: how to get -march=native's value? 2021-09-17 10:26 ` Jonathan Wakely @ 2021-09-17 10:38 ` Jonathan Wakely 2021-09-17 17:53 ` Segher Boessenkool 1 sibling, 0 replies; 15+ messages in thread From: Jonathan Wakely @ 2021-09-17 10:38 UTC (permalink / raw) To: Xi Ruoyao; +Cc: NightStrike, gcc-help, unlvsur unlvsur 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: how to get -march=native's value? 2021-09-17 10:26 ` Jonathan Wakely 2021-09-17 10:38 ` Jonathan Wakely @ 2021-09-17 17:53 ` Segher Boessenkool 2021-09-27 12:55 ` Vincent Lefevre 1 sibling, 1 reply; 15+ messages in thread From: Segher Boessenkool @ 2021-09-17 17:53 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Xi Ruoyao, gcc-help, unlvsur unlvsur 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: how to get -march=native's value? 2021-09-17 17:53 ` Segher Boessenkool @ 2021-09-27 12:55 ` Vincent Lefevre 2021-09-27 17:13 ` Segher Boessenkool 0 siblings, 1 reply; 15+ messages in thread From: Vincent Lefevre @ 2021-09-27 12:55 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Jonathan Wakely, gcc-help, unlvsur unlvsur 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) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: how to get -march=native's value? 2021-09-27 12:55 ` Vincent Lefevre @ 2021-09-27 17:13 ` Segher Boessenkool 2021-09-27 18:14 ` L A Walsh 0 siblings, 1 reply; 15+ messages in thread From: Segher Boessenkool @ 2021-09-27 17:13 UTC (permalink / raw) To: Jonathan Wakely, gcc-help, unlvsur unlvsur 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: how to get -march=native's value? 2021-09-27 17:13 ` Segher Boessenkool @ 2021-09-27 18:14 ` L A Walsh 2021-09-27 18:25 ` Jonathan Wakely 2021-09-27 18:26 ` Florian Weimer 0 siblings, 2 replies; 15+ messages in thread From: L A Walsh @ 2021-09-27 18:14 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Jonathan Wakely, gcc-help, unlvsur unlvsur 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 (?). ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: how to get -march=native's value? 2021-09-27 18:14 ` L A Walsh @ 2021-09-27 18:25 ` Jonathan Wakely 2021-09-27 20:26 ` Segher Boessenkool 2021-09-27 18:26 ` Florian Weimer 1 sibling, 1 reply; 15+ messages in thread From: Jonathan Wakely @ 2021-09-27 18:25 UTC (permalink / raw) To: L A Walsh; +Cc: Segher Boessenkool, gcc-help, unlvsur unlvsur 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 :-) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: how to get -march=native's value? 2021-09-27 18:25 ` Jonathan Wakely @ 2021-09-27 20:26 ` Segher Boessenkool 2021-09-27 20:30 ` NightStrike 0 siblings, 1 reply; 15+ messages in thread From: Segher Boessenkool @ 2021-09-27 20:26 UTC (permalink / raw) To: Jonathan Wakely; +Cc: L A Walsh, gcc-help, unlvsur unlvsur 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: how to get -march=native's value? 2021-09-27 20:26 ` Segher Boessenkool @ 2021-09-27 20:30 ` NightStrike 0 siblings, 0 replies; 15+ messages in thread From: NightStrike @ 2021-09-27 20:30 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Jonathan Wakely, gcc-help, unlvsur unlvsur 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: how to get -march=native's value? 2021-09-27 18:14 ` L A Walsh 2021-09-27 18:25 ` Jonathan Wakely @ 2021-09-27 18:26 ` Florian Weimer 1 sibling, 0 replies; 15+ messages in thread From: Florian Weimer @ 2021-09-27 18:26 UTC (permalink / raw) To: L A Walsh; +Cc: Segher Boessenkool, gcc-help, unlvsur unlvsur * 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: how to get -march=native's value? 2021-09-07 7:02 how to get -march=native's value? unlvsur unlvsur 2021-09-07 7:56 ` Jonathan Wakely @ 2021-09-07 7:59 ` Hongtao Liu 1 sibling, 0 replies; 15+ messages in thread From: Hongtao Liu @ 2021-09-07 7:59 UTC (permalink / raw) To: unlvsur unlvsur; +Cc: gcc-help 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2021-09-27 20:30 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-07 7:02 how to get -march=native's value? unlvsur unlvsur 2021-09-07 7:56 ` Jonathan Wakely 2021-09-17 2:46 ` NightStrike 2021-09-17 8:29 ` Xi Ruoyao 2021-09-17 10:26 ` Jonathan Wakely 2021-09-17 10:38 ` Jonathan Wakely 2021-09-17 17:53 ` Segher Boessenkool 2021-09-27 12:55 ` Vincent Lefevre 2021-09-27 17:13 ` Segher Boessenkool 2021-09-27 18:14 ` L A Walsh 2021-09-27 18:25 ` Jonathan Wakely 2021-09-27 20:26 ` Segher Boessenkool 2021-09-27 20:30 ` NightStrike 2021-09-27 18:26 ` Florian Weimer 2021-09-07 7:59 ` Hongtao Liu
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).