how to get -march=native's value?
Jonathan Wakely
jwakely.gcc@gmail.com
Fri Sep 17 10:38:15 GMT 2021
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.
More information about the Gcc-help
mailing list