Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
march vs mtune
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Mike81
n00b
n00b


Joined: 05 Jan 2011
Posts: 39

PostPosted: Fri Mar 07, 2014 11:07 pm    Post subject: march vs mtune Reply with quote

Hi,

since I started using Gentoo (AFAIR I started when GCC 4.5.x was current; now I am using 4.8.2) I set march and mtune.

~2 years ago I read in the old Gentoo wiki in the hardware flags/CFlags articles, that it is recommended to set march=yourcpu but mtune=generic due to some problems with gcc. I am unable to find these articles again.

Now after some years and reading more about GCC I am not sure if you really should set march and mtune together (i.e. mtune would override march?)... that you should only set mtune or march.

So what is right:
  • Set only march or mtune
  • Setting both options is no problem


And finally I have a question regarding mtune/march in general. It is right to say
Quote:
Setting march to "core-avx-i" for example will limit/require a processor with the features an IvyBridge processor is offering.

Quote:
Setting mtune to "core-avx-i" for example will optimize the binary for IvyBridge processors but if you have also set march to x86_64 for example your AMD Opteron processor should be able to run the binary at least (without optimization).

Well, I think if I am right I answered the first question in parts (=setting both values is supported and not a problem, e.g. nothing is overriding the other option).
If this is right, this will raise my last question:

Does it make sense to set march=<your-cpu> but keep mtune=generic?

Thanks!
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21518

PostPosted: Sat Mar 08, 2014 1:58 am    Post subject: Reply with quote

If mtune is unset, it defaults to march. Setting march higher than mtune should produce a correct binary, but is nonsensical. If you grant the compiler permission to use advanced features, then you know you cannot guarantee it will run on a basic CPU, so why tune for that basic CPU? The only reason to set both would be if you allow use of features from a generation N CPU, but optimize on the assumption most systems will be running a generation N+M CPU. In that case, the program will run on anything that satisfies march, but may run better on things that also satisfy mtune.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Mar 08, 2014 4:51 am    Post subject: Reply with quote

What Hu said, as usual. IOW: No.
Back to top
View user's profile Send private message
vaxbrat
l33t
l33t


Joined: 05 Oct 2005
Posts: 731
Location: DC Burbs

PostPosted: Sat Mar 08, 2014 6:41 am    Post subject: march versus mtune Reply with quote

Think of -march as setting your least common denominator and -mtune as what you think the various platforms that you might deploy on will have. For example the least common denominator for an x86 32 bit build would probably be -march=i686 which corresponds to at least a pentiumpro instruction set with mmx and sse instructions. You then might set -mtune=prescott which is basically the end of the line for pentium 4.

If you set march too high, a processor without all of the fiddly bit features (eg, sse2, sse3, sse4, etc) that you said you had with for example a -march=westmere will probably cause random stuff to core dump. A good stress test when tweaking your flags is to attempt to build gcc and then see whether stage2 blows up with something like an "internal compiler error".

One good strategy might be to set -march to something generic and then mtune=native. Odds are that your build machine is your best machine so you are telling it to tune up to whatever it might have for features. I think the generated code from gcc will attempt to run with the best instructions possible and then fall back to generic instructions when a TRAP gets sprung.
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Sat Mar 08, 2014 9:00 am    Post subject: Reply with quote

The point with gcc's mtune is not that much if you should set it or not, the real point (I mean the one that actually makes a real difference in terms of performances) is if you should set mtune to generic or not.
gcc doc wrote:
generic : Produce code optimized for the most common IA32/AMD64/EM64T processors.

But then the advice given is just... purely theoretical :
gcc doc wrote:
If you know the CPU on which your code will run, then you should use the corresponding -mtune option instead of -mtune=generic. But, if you do not know exactly what CPU users of your application will have, then you should use this option.

It has been demonstrated (at least at the kernel level) with a couple of versions of gcc that if you had an Intel Core2, gcc was producing a more efficient code for you using -march=core2 AND -mtune=generic than when using -march=core2 AND -mtune=core2 or -mtune=native or not setting mtune which, as Hu wrote are equivalent.
That is exactly why you can read in the kernel's x86arch Makefile:
Code:
cflags-$(CONFIG_MCORE2) += \
                $(call cc-option,-march=core2,$(call cc-option,-mtune=generic))

The real problem comes next:
gcc doc wrote:
As new processors are deployed in the marketplace, the behavior of this option will change. Therefore, if you upgrade to a newer version of GCC, the code generated option will change to reflect the processors that were most common when that version of GCC was released.

Leading to the conclusion that... each time you upgrade gcc... you should test by yourself if -march=yourarch AND -mtune=generic, produces more efficient code than -march=yourarch only, or not. :twisted:
_________________
Back to top
View user's profile Send private message
Mike81
n00b
n00b


Joined: 05 Jan 2011
Posts: 39

PostPosted: Sat Mar 08, 2014 9:52 am    Post subject: Reply with quote

Thank you all for all your replies but I am not sure if I understand everything:

Hu, steveL, vaxbrat and also aCOSwt (in the first half of his posting) said if GCC supports my proccessor I should also set mtune.

But in aCOSwt second half he said that using mtune=generic produces better code and quoted kernel's Makefile to proof?!

So should I now keep mtune=generic or should I set it to the same value I use for march if my processor has a GCC profile (and it has)?

Quote:
Leading to the conclusion that... each time you upgrade gcc... you should test by yourself if -march=yourarch AND -mtune=generic, produces more efficient code than -march=yourarch only, or not. :twisted:
That sounds very interesting. How do I actual test if mtune=generic or mtune=core-avx-i for my IvyBridge processor produces better code?
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Sat Mar 08, 2014 11:50 am    Post subject: Reply with quote

Mike81 wrote:
Hu, steveL, vaxbrat and also aCOSwt (in the first half of his posting) said if GCC supports my proccessor I should also set mtune.

Yes because that is theoretically correct. That is how gcc devs intend things to be working.
Mike81 wrote:
But in aCOSwt second half he said that using mtune=generic produces better code and quoted kernel's Makefile to proof?!

I wrote that, occasionally, (if not more or less sytematically :roll: ) on your system hic&nunc, with a given version of gcc and a given processor and a given piece of code, it may happens (and it actually happened more than once) that mtune=generic produces *far* better code.
Mike81 wrote:
How do I actual test if mtune=generic or mtune=core-avx-i for my IvyBridge processor produces better code?

Well, that's trivial but... not easy.
As a matter of fact, I personally discovered that when coding a driver for FreeBSD, debugging and optimizing it, then upgrading gcc and then just observe that I could not recognize some parts of the assembly code. 8O
From a non dev stanpoint, I'd say that at the very least, you must be able to set breakpoints in some code.

From a personal standpoint, I stopped benchmarking that sort of things for a while and will stick to -mtune=generic as long as kernel devs stick to it.
_________________
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21518

PostPosted: Sat Mar 08, 2014 4:30 pm    Post subject: Re: march versus mtune Reply with quote

vaxbrat wrote:
If you set march too high, a processor without all of the fiddly bit features (eg, sse2, sse3, sse4, etc) that you said you had with for example a -march=westmere will probably cause random stuff to core dump.
Although core files are produced, the usual failure mode for using a CPU less capable than the one given by -march is to receive a SIGILL.
vaxbrat wrote:
I think the generated code from gcc will attempt to run with the best instructions possible and then fall back to generic instructions when a TRAP gets sprung.
I believe this is incorrect. Although you can trap a SIGILL and try to fall back to a lower CPU type, and some advanced programs may do this or other tricks, using -march on C code that has no special handling will produce code that requires the instruction to exist and will not have a fallback. You can see this by compiling a simple function that is eligible for cmov once with a -march that enables it and again with a -march that does not enable it.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54119
Location: 56N 3W

PostPosted: Sat Mar 08, 2014 7:00 pm    Post subject: Reply with quote

Mike81,

Beware optimisation ... its an average thing.

What's best for the kernel may not be best for other packages. You would need to test.
You can set CFLAGS on a per package basis ... but life is far too short.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Mar 08, 2014 7:11 pm    Post subject: Reply with quote

Um I was answering: "Does it make sense to set march=<your-cpu> but keep mtune=generic?" with "No".

I'd never heard of what aCos is talking about though. arch is minimum, so if your CPU is not the same (given a specific one) then it won't work. tune is what to make use of, if available, so if it's not there then things won't fall apart. To my mind just setting march is enough, since tune will go with the same setting, and if it's the machine you're building on which will run the software, or (as I do) you have two machines with the exact same CPU, you can use -march=native, which means it picks up on the cache(-line)-sizes and builds for the machine it's compiled on. In general I'd use that, for a native install (which is what many of us run.)

If you know that aCos' approach will work (ie you are on core2 and you are on the correct version of gcc) then by all means try it. Personally I'm not going to bother, as I like -march=native, and I also set a few other flags to make my build small, while still using -O2 and not -Os. Those aren't recommended though, so I won't go into them.

Additionally you can do a lot by setting per-package CFLAGS via /etc/portage/package.env -- see this post.
Back to top
View user's profile Send private message
Mike81
n00b
n00b


Joined: 05 Jan 2011
Posts: 39

PostPosted: Sun Mar 09, 2014 11:03 am    Post subject: Reply with quote

aCOSwt wrote:
From a personal standpoint, I stopped benchmarking that sort of things for a while and will stick to -mtune=generic as long as kernel devs stick to it.
NeddySeagoon wrote:
You can set CFLAGS on a per package basis ... but life is far too short.
Full acknowledgement.

I am only concerned about the question if anything positive -march may add will be removed/neglected due to -mtune=generic. But I am still unsure if I now understand:

@steveL: Anything with =native is not an option for me, because I have a bunch of different x86-64 systems which are helping each other to compile using distcc. So each system has to specify "Please compile for march=<specific>..." and not native which would fall back to the architecture the distcc node helping out is running (or am I wrong?).

So I am still unsure if an IvyBridge system should set something like
Code:
CFLAGS="-march=core-avx-i"
CFLAGS="${CFLAGS} -mno-movbe -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop"
CFLAGS="${CFLAGS} -mno-bmi -mno-bmi2 -mno-tbm -mno-avx2 -mno-lzcnt -mno-rtm"
CFLAGS="${CFLAGS} -mno-hle -mno-rdseed -mno-prfchw -mno-adx -mxsave -mxsaveopt"

CFLAGS="${CFLAGS} --param l1-cache-size=32"
CFLAGS="${CFLAGS} --param l1-cache-line-size=64"
CFLAGS="${CFLAGS} --param l2-cache-size=8192"
CFLAGS="${CFLAGS} -mtune=generic"
or
Code:
CFLAGS="-march=core-avx-i"
CFLAGS="${CFLAGS} -mno-movbe -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop"
CFLAGS="${CFLAGS} -mno-bmi -mno-bmi2 -mno-tbm -mno-avx2 -mno-lzcnt -mno-rtm"
CFLAGS="${CFLAGS} -mno-hle -mno-rdseed -mno-prfchw -mno-adx -mxsave -mxsaveopt"

CFLAGS="${CFLAGS} --param l1-cache-size=32"
CFLAGS="${CFLAGS} --param l1-cache-line-size=64"
CFLAGS="${CFLAGS} --param l2-cache-size=8192"
CFLAGS="${CFLAGS} -mtune=core-avx-i"
I tend to set -march and -mtune to the same explicit value.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54119
Location: 56N 3W

PostPosted: Sun Mar 09, 2014 2:40 pm    Post subject: Reply with quote

Mike81,

For distcc, on each box, run one of the many one lines that tell what -march=native gets you and but that in its CFLAGS.

You are correct taht you may not use -march=native and distcc. distcc will always build locally if you try it.
The -march=native explicit substitution works.

If each box builds for itself using distcc thats fine. You may nave problems sharing binaries.

-- edit --

I was going to be lazy ...
Code:
$ gcc -march=native -E -v - </dev/null 2>&1 | grep cc1
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/cc1 -E -quiet -v - -march=amdfam10 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mabm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10
is what I get.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Mar 09, 2014 7:07 pm    Post subject: Reply with quote

Mike81 wrote:
I am only concerned about the question if anything positive -march may add will be removed/neglected due to -mtune=generic. But I am still unsure if I now understand

And that is the question I have answered with "yes", quite unequivocally afaic.

For instance if your arch is sse-4.1 capable then tuning for a generic architecture means it won't rely on those insns. The standard method has always been arch="more generic" tune="more functional" so that it uses better CPU insns if available, but will still run on the more generic selection. Do you understand that usage? It's the most basic method, and has always been around.

However it sounds like something has changed recently in gcc. Perhaps it is now the case that it takes arch as minimum and then tunes from there. So if you've told it "minimum is a core2 duo" then to "tune generically" it likely means it's already going to use eg ssse-3 and then the decision is what other insns it will allow. To my mind it should tune for the same arch, however it may be that causes extra work (eg an extra stage is carried out) which is in fact not very useful when the arch is already set.

The only way to find that out is to do some research. (asking people on the forums is not it.)
Back to top
View user's profile Send private message
nlsa8z6zoz7lyih3ap
Guru
Guru


Joined: 25 Sep 2007
Posts: 388
Location: Canada

PostPosted: Mon Mar 10, 2014 4:18 am    Post subject: Reply with quote

Quote:
IOW: No


What does this mean?
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Mon Mar 10, 2014 10:13 am    Post subject: Reply with quote

nlsa8z6zoz7lyih3ap wrote:
Quote:
IOW: No

What does this mean?

It means if you invert the sense of the question you get the opposite answer.

Again, I qualify this by saying this is how it always has been; gcc 4 has gone through some major changes.

Personally I'd see what -march=native comes up with on the CHOST in question, and stick that in make.conf for the relevant PORTAGE_CONFIGROOT.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7470

PostPosted: Mon Mar 10, 2014 12:41 pm    Post subject: Reply with quote

aCOSwt wrote:

It has been demonstrated (at least at the kernel level) with a couple of versions of gcc that if you had an Intel Core2, gcc was producing a more efficient code for you using -march=core2 AND -mtune=generic than when using -march=core2 AND -mtune=core2 or -mtune=native or not setting mtune which, as Hu wrote are equivalent.
That is exactly why you can read in the kernel's x86arch Makefile:
Code:
cflags-$(CONFIG_MCORE2) += \
                $(call cc-option,-march=core2,$(call cc-option,-mtune=generic))



Kernel only provide the cpu familly (CONFIG_CORE2 is not the same as CONFIG_CORE2_MODEL4). So if kernel wants to make sure it could run on ANY core2 family it must pass the -mtune=generic else a new model may fail if gcc is unaware of it. Intel could really alter models of the same family (or just because of bugs on a specific model).

So kernel must gave the option of the model or force generic to make sure it will always works.
I don't think any benchmark is need to make the choice, just some logic. The same force (by logic) choice binary distro must do.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Mon Mar 10, 2014 8:38 pm    Post subject: Reply with quote

Ah good point krinn. kernel must run on new CPUs in the same family, unless you know it's not going to be used on other CPUs.
Back to top
View user's profile Send private message
rhill
Retired Dev
Retired Dev


Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca

PostPosted: Tue Mar 11, 2014 3:38 am    Post subject: Reply with quote

-march determines what instruction sets are used in the outputted binary. An instruction set is the list of commands implemented by the hardware, ie. the commands the CPU understands. If you try to run a binary built with -march=corei7avx and run it on a core2, it's going to be all 'wtf is a vzeroupper?'. All the fancy -m* options you see crazy people using are set by -march.

-mtune determines the cost model that is used when generating code. The cost model describes how long it takes the CPU to do things. eg. it takes this processor 22 cycles to do a divide operation, or we should prefer doing integer moves rather than copies here because they're less expensive. This information is then used by the scheduler to decide what operations to use and in what order. Using the wrong -mtune value will not break anything, but it might slow it down a tiny tiny bit. -mtune cannot "undo" what -march does because they're completely different things. -mtune=generic is a set of options that provide good performance across the majority of Intel/AMD processors - the things they have in common.

Not all processors have a cost model. It takes a lot of tedious work, usually donated by the processor companies. IIRC core2 was added to GCC in 4.3 but didn't have a cost model until 4.7. That's why you would get better performance with -mtune=generic - even if it wasn't /optimal/, it was better than nothing. And that's why GCC defaulted to -mtune=generic on these processors when -march=native was used.

When should you use -mtune=generic and when should you use -mtune=mycpu? Check what -march=native would do and then do that. Or better yet, just use -march=native. But really you can't go wrong with generic. It's pretty well tuned.
_________________
by design, by neglect
for a fact or just for effect


Last edited by rhill on Tue Mar 11, 2014 4:05 am; edited 1 time in total
Back to top
View user's profile Send private message
rhill
Retired Dev
Retired Dev


Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca

PostPosted: Tue Mar 11, 2014 3:45 am    Post subject: Reply with quote

Mike81 wrote:

So I am still unsure if an IvyBridge system should set something like
Code:
CFLAGS="-march=core-avx-i"
CFLAGS="${CFLAGS} -mno-movbe -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop"
CFLAGS="${CFLAGS} -mno-bmi -mno-bmi2 -mno-tbm -mno-avx2 -mno-lzcnt -mno-rtm"
CFLAGS="${CFLAGS} -mno-hle -mno-rdseed -mno-prfchw -mno-adx "

CFLAGS="${CFLAGS} --param l1-cache-size=32"
CFLAGS="${CFLAGS} --param l1-cache-line-size=64"
CFLAGS="${CFLAGS} --param l2-cache-size=8192"
CFLAGS="${CFLAGS} -mtune=generic"
or
Code:
CFLAGS="-march=core-avx-i"
CFLAGS="${CFLAGS} -mno-movbe -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop"
CFLAGS="${CFLAGS} -mno-bmi -mno-bmi2 -mno-tbm -mno-avx2 -mno-lzcnt -mno-rtm"
CFLAGS="${CFLAGS} -mno-hle -mno-rdseed -mno-prfchw -mno-adx -mxsave -mxsaveopt"

CFLAGS="${CFLAGS} --param l1-cache-size=32"
CFLAGS="${CFLAGS} --param l1-cache-line-size=64"
CFLAGS="${CFLAGS} --param l2-cache-size=8192"
CFLAGS="${CFLAGS} -mtune=core-avx-i"


Aagh mine freakin eyes!

Okay, do this

Code:
CFLAGS="-march=core-avx-i"
CFLAGS="${CFLAGS} -mxsave -mxsaveopt"
CFLAGS="${CFLAGS} -mtune=core-avx-i"


It's the exact same thing except I'd actually accept that in a bug report.
_________________
by design, by neglect
for a fact or just for effect
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Tue Mar 11, 2014 4:38 am    Post subject: Reply with quote

rhill wrote:
Aagh mine freakin eyes!

Okay, do this
Code:
CFLAGS="-march=core-avx-i"
CFLAGS="${CFLAGS} -mxsave -mxsaveopt"
CFLAGS="${CFLAGS} -mtune=core-avx-i"


It's the exact same thing except I'd actually accept that in a bug report.

He wants the same thing as -march=native over distcc; not sure about insn availability (reasonable that you don't have to turn off what's not there), but cache-sizes aren't available otherwise.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7470

PostPosted: Tue Mar 11, 2014 9:31 am    Post subject: Reply with quote

rhill wrote:

Code:
CFLAGS="-march=core-avx-i"
CFLAGS="${CFLAGS} -mxsave -mxsaveopt"
CFLAGS="${CFLAGS} -mtune=core-avx-i"


It's the exact same thing except I'd actually accept that in a bug report.

It's not the exact same thing, it should, but it's not :
Code:
gcc -Q -march=corei7 -mtune=corei7 --help=target |egrep '(march|mtune|enabled)'
  -m32                              [enabled]
  -m80387                           [enabled]
  -m96bit-long-double               [enabled]
  -malign-stringops                 [enabled]
  -march=                           corei7
  -mfancy-math-387                  [enabled]
  -mfentry                          [enabled]
  -mfp-ret-in-387                   [enabled]
  -mglibc                           [enabled]
  -mhard-float                      [enabled]
  -mieee-fp                         [enabled]
  -mno-sse4                         [enabled]
  -mpush-args                       [enabled]
  -mred-zone                        [enabled]
  -mstackrealign                    [enabled]
  -mtls-direct-seg-refs             [enabled]
  -mtune=                           corei7

Code:
gcc -Q -march=native --help=target |egrep '(march|mtune|enabled)'
  -m32                              [enabled]
  -m80387                           [enabled]
  -m96bit-long-double               [enabled]
  -malign-stringops                 [enabled]
  -march=                           corei7
  -mcx16                            [enabled]
  -mfancy-math-387                  [enabled]
  -mfentry                          [enabled]
  -mfp-ret-in-387                   [enabled]
  -mglibc                           [enabled]
  -mhard-float                      [enabled]
  -mieee-fp                         [enabled]
  -mpopcnt                          [enabled]
  -mpush-args                       [enabled]
  -mred-zone                        [enabled]
  -msahf                            [enabled]
  -msse                             [enabled]
  -msse2                            [enabled]
  -msse3                            [enabled]
  -msse4                            [enabled]
  -msse4.1                          [enabled]
  -msse4.2                          [enabled]
  -mssse3                           [enabled]
  -mstackrealign                    [enabled]
  -mtls-direct-seg-refs             [enabled]
  -mtune=                           corei7

Sure everyone could said gcc enable sse when using mtune=corei7, this is expect for that arch no? But for whatever reason, it doesn't output it when not using native.
So in doubt : forcing -msse* setttings and any settings you get when using native for your cpu won't kill anyone, just making sure gcc is doing what you expect it to do.

I'm surprise you won't support anyone that specify settings in its cflags that are enable by native to make sure they are indeed just enable when not using native, it's what i do on my hosts, and the only not "default" setting i have is mfpmath, so my cflags is big, but there 0 racing setting in it.

Does it mean i must sent you glasses if i bugreport something on gentoo ?
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Tue Mar 11, 2014 10:12 am    Post subject: Reply with quote

krinn wrote:
It's the exact same thing except I'd actually accept that in a bug report.
It's not the exact same thing, it should, but it's not :


I think what he meant is that the flags as set with the long quote, are all being set natively.
The difference is that you get more if one uses march=native.
The compiler understands the chips capability, in other words

I don't know why anyone would want to not turn on sse or avx or whatever instructions
with the exception of building a binary for a processor on another machine.
But it's easy enough to set march=native and then turn off any instruction one doesn't want.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7470

PostPosted: Tue Mar 11, 2014 10:14 am    Post subject: Reply with quote

Anon-E-moose wrote:

I don't know why anyone would want to not turn on sse or avx or whatever instructions
with the exception of building a binary for a processor on another machine.
But it's easy enough to set march=native and then turn off any instruction one doesn't want.

Because like many i use distcc
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Tue Mar 11, 2014 10:18 am    Post subject: Reply with quote

krinn wrote:
Anon-E-moose wrote:

I don't know why anyone would want to not turn on sse or avx or whatever instructions
with the exception of building a binary for a processor on another machine.
But it's easy enough to set march=native and then turn off any instruction one doesn't want.

Because like many i use distcc


Then the simple answer is to set to march to generic.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7470

PostPosted: Tue Mar 11, 2014 10:26 am    Post subject: Reply with quote

there's no generic march setting, but in case you miss it :
Code:
gcc -Q -march=i686 -mtune=generic --help=target |egrep '(march|mtune|enabled)'
  -m32                              [enabled]
  -m80387                           [enabled]
  -m96bit-long-double               [enabled]
  -malign-stringops                 [enabled]
  -march=                           i686
  -mfancy-math-387                  [enabled]
  -mfentry                          [enabled]
  -mfp-ret-in-387                   [enabled]
  -mglibc                           [enabled]
  -mhard-float                      [enabled]
  -mieee-fp                         [enabled]
  -mno-sse4                         [enabled]
  -mpush-args                       [enabled]
  -mred-zone                        [enabled]
  -mstackrealign                    [enabled]
  -mtls-direct-seg-refs             [enabled]
  -mtune=                           generic
gcc -Q -march=corei7 -mtune=generic --help=target |egrep '(march|mtune|enabled)'
  -m32                              [enabled]
  -m80387                           [enabled]
  -m96bit-long-double               [enabled]
  -malign-stringops                 [enabled]
  -march=                           corei7
  -mfancy-math-387                  [enabled]
  -mfentry                          [enabled]
  -mfp-ret-in-387                   [enabled]
  -mglibc                           [enabled]
  -mhard-float                      [enabled]
  -mieee-fp                         [enabled]
  -mno-sse4                         [enabled]
  -mpush-args                       [enabled]
  -mred-zone                        [enabled]
  -mstackrealign                    [enabled]
  -mtls-direct-seg-refs             [enabled]
  -mtune=                           generic


Using generic doesn't help so...
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum