On Fri, 17 Sept 2021 at 11:26, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> 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@xxxxxxxxxxx> wrote: > > > > > > > > On Tue, 7 Sep 2021, 08:03 unlvsur unlvsur via Gcc-help, < > > > > gcc-help@xxxxxxxxxxx> 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.
