View previous topic :: View next topic |
Author |
Message |
Maedhros Bodhisattva
Joined: 14 Apr 2004 Posts: 5511 Location: Durham, UK
|
Posted: Wed May 04, 2005 8:53 pm Post subject: CFLAGS Central (Part 2) |
|
|
Continued from CFLAGS Central (Part 1) _________________ No-one's more important than the earthworm. |
|
Back to top |
|
|
elvisthedj Guru
Joined: 21 Jun 2004 Posts: 483 Location: Nampa, ID
|
Posted: Wed May 04, 2005 10:41 pm Post subject: |
|
|
Code: |
CFLAGS="-O2 -march=athlon-xp -pipe -mcpu=i686 -fomit-frame-pointer -msse -mmmx -m3dnow -ffast-math -fprefetch-loop-arrays -finline-limit=600 -ftracer
|
I just realized that I'm some point I've added some P4 specific flags to my athlon xp make.conf .. yet, I haven't broken anything. Do these flags (-msse -mmmx -m3dnow) jus get ignored? Does gcc just think i'm a retard? do you guys??
edit: I remember why I did this. mplayer If I ran it, it was saying ".... supported, but not enabled" or some such thing.
So I added those flags and recompiled and I guess I just never took them out.
Code: |
MPlayer 1.0pre6-3.3.5-20050130 (C) 2000-2004 MPlayer Team
CPU: Advanced Micro Devices Athlon 4 /Athlon MP/XP Palomino (Family: 6, Stepping: 2)
Detected cache-line size is 64 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE
Warning unknown option cache_min at line 144
Warning unknown option cache_prefill at line 14
|
So, are these not "pentium specific" .. hmmm.. perhaps I should read the other 35 pages of the thread _________________ Kris Edwards
kris edwards at g mail dot c0m
PGP
WWW |
|
Back to top |
|
|
moocha Watchman
Joined: 21 Oct 2003 Posts: 5722
|
Posted: Thu May 05, 2005 3:06 am Post subject: |
|
|
- -mmmx: Not P4-specific. Supported since Pentium-MMX and AMD K6 (the later revisions).
- -msse: Not P4-specific. Supported since Pentium 3 and AMD Athlon / Duron.
- -m3dnow: Not P4-specific, in fact AMD-specific. Supported since AMD K6-2.
_________________ Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
Back to top |
|
|
Gherald Veteran
Joined: 23 Aug 2004 Posts: 1399 Location: CLUAConsole
|
Posted: Thu May 05, 2005 3:18 am Post subject: |
|
|
yay, giant thread gone, I can get some personal attention
How's this: Code: | CFLAGS="-march=pentium-m -pipe -mmmx -msse -msse2 -mfpmath=sse \
-fomit-frame-pointer -momit-leaf-frame-pointer -funit-at-a-time -frename-registers \
-O2 -Os -fno-align-functions -fno-align-jumps -fno-align-loops \
-fno-align-labels -fno-reorder-blocks -fno-prefetch-loop-arrays" |
I'm assuming the rightmost flag has priority in resolving conflicts... but perhaps I've got that backwards? |
|
Back to top |
|
|
elvisthedj Guru
Joined: 21 Jun 2004 Posts: 483 Location: Nampa, ID
|
Posted: Thu May 05, 2005 3:50 am Post subject: |
|
|
Quote: |
* -mmmx: Not P4-specific. Supported since Pentium-MMX and AMD K6 (the later revisions).
* -msse: Not P4-specific. Supported since Pentium 3 and AMD Athlon / Duron.
* -m3dnow: Not P4-specific, in fact AMD-specific. Supported since AMD K6-2.
|
ty. I notice that these are on the "safe list" for p4 and not for amd.
http://gentoo-wiki.com/Safe_Cflags
Anyone have a good reason any or all might be "unsafe"? (for desktop environment) _________________ Kris Edwards
kris edwards at g mail dot c0m
PGP
WWW |
|
Back to top |
|
|
codergeek42 Bodhisattva
Joined: 05 Apr 2004 Posts: 5142 Location: Anaheim, CA (USA)
|
Posted: Thu May 05, 2005 4:37 am Post subject: |
|
|
You don't need to add those though. The proper MMX/SSE/3DNow! options are implied by your "-march=" setting. _________________ ~~ Peter: Programmer, Mathematician, STEM & Free Software Advocate, Enlightened Agent, Transhumanist, Fedora contributor
Who am I? :: EFF & FSF |
|
Back to top |
|
|
Gherald Veteran
Joined: 23 Aug 2004 Posts: 1399 Location: CLUAConsole
|
Posted: Thu May 05, 2005 4:46 am Post subject: |
|
|
codergeek42 wrote: | You don't need to add those though. The proper MMX/SSE/3DNow! options are implied by your "-march=" setting. | I do not understand why some people think there is a reason to not use flags which are already implied by a previous flag. Ebuilds, particularly poorly written ones, might filter out a general flag like -march but leave something like -mmmx intact.
Notice that I use both -O2 and -Os. |
|
Back to top |
|
|
elvisthedj Guru
Joined: 21 Jun 2004 Posts: 483 Location: Nampa, ID
|
Posted: Thu May 05, 2005 5:10 am Post subject: |
|
|
Quote: |
You don't need to add those though. The proper MMX/SSE/3DNow! options are implied by your "-march=" setting
|
Makes sense to me.. Seems like I distinctly remember having to add these for mplayer though. If I didn't use mplayer so often, I'd re-emerge it w/o them so I could see the original messages. But, instead I'll go check to see I overlooked some mplayer use flags _________________ Kris Edwards
kris edwards at g mail dot c0m
PGP
WWW |
|
Back to top |
|
|
Gherald Veteran
Joined: 23 Aug 2004 Posts: 1399 Location: CLUAConsole
|
Posted: Thu May 05, 2005 5:19 am Post subject: |
|
|
I thought mplayer ignored most CFLAGS... |
|
Back to top |
|
|
codergeek42 Bodhisattva
Joined: 05 Apr 2004 Posts: 5142 Location: Anaheim, CA (USA)
|
Posted: Thu May 05, 2005 5:23 am Post subject: |
|
|
Yup. That's why it has mmx, mmxext, sse, sse2, 3dnow, and 3dnowext USE flags. _________________ ~~ Peter: Programmer, Mathematician, STEM & Free Software Advocate, Enlightened Agent, Transhumanist, Fedora contributor
Who am I? :: EFF & FSF |
|
Back to top |
|
|
elvisthedj Guru
Joined: 21 Jun 2004 Posts: 483 Location: Nampa, ID
|
Posted: Thu May 05, 2005 5:42 am Post subject: |
|
|
codergeek42 says:
Quote: |
Yup. That's why it has mmx, mmxext, sse, sse2, 3dnow, and 3dnowext USE flags
|
mplayer's ebuild says:
Quote: |
# let's play the filtration game! MPlayer hates on all!
strip-flags
|
sometimes I do weird things and spend too much time trying to figure out why. I'm just going to quietly step away from the thread. _________________ Kris Edwards
kris edwards at g mail dot c0m
PGP
WWW |
|
Back to top |
|
|
moocha Watchman
Joined: 21 Oct 2003 Posts: 5722
|
Posted: Thu May 05, 2005 9:31 am Post subject: |
|
|
Gherald wrote: | yay, giant thread gone, I can get some personal attention
How's this: Code: | CFLAGS="-march=pentium-m -pipe -mmmx -msse -msse2 -mfpmath=sse \
-fomit-frame-pointer -momit-leaf-frame-pointer -funit-at-a-time -frename-registers \
-O2 -Os -fno-align-functions -fno-align-jumps -fno-align-loops \
-fno-align-labels -fno-reorder-blocks -fno-prefetch-loop-arrays" |
|
No, no, no, No, NO. Read this thread and learn one or two things about the concept of optimization before doing that to your system. Gherald wrote: | I do not understand why some people think there is a reason to not use flags which are already implied by a previous flag. | Because some people actually know better, out of dire experience... Gherald wrote: | Ebuilds, particularly poorly written ones, might filter out a general flag like -march but leave something like -mmmx intact. | And might break horribly. Gherald wrote: | Notice that I use both -O2 and -Os. | Which you shouldn't, unless you don't like glibc. There was a bug last year that would kill your glibc if you built it with two -O flags in your CFLAGS. Who's to know if and when that might happen again? _________________ Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
Back to top |
|
|
Gherald Veteran
Joined: 23 Aug 2004 Posts: 1399 Location: CLUAConsole
|
Posted: Thu May 05, 2005 9:46 am Post subject: |
|
|
moocha wrote: | Gherald wrote: | Code: | CFLAGS="-march=pentium-m -pipe -mmmx -msse -msse2 -mfpmath=sse \
-fomit-frame-pointer -momit-leaf-frame-pointer -funit-at-a-time -frename-registers \
-O2 -Os -fno-align-functions -fno-align-jumps -fno-align-loops \
-fno-align-labels -fno-reorder-blocks -fno-prefetch-loop-arrays" |
|
No, no, no, No, NO. Read this thread and learn one or two things about the concept of optimization before doing that to your system. |
So you object to -mmmx -msse -msse2 and -mfpmath=sse. I've looked into each of them and they seem safe and appropriate.
Quote: | Gherald wrote: | Ebuilds, particularly poorly written ones, might filter out a general flag like -march but leave something like -mmmx intact. | And might break horribly. |
Eh? -mmmx is a perfectly sensible CFLAG that has been around for *very* long time and if an ebuild were to fail because of it, I'd simply uncomment one of the other two settings I keep in make.conf for poor quality ebuilds...
Code: | #CFLAGS="-march=i686 -pipe -fomit-frame-pointer"
#CFLAGS="-march=pentium3 -O2 -pipe -fomit-frame-pointer" |
I haven't had to use either of those ever since kdemultimedia got its act together.
Quote: | Gherald wrote: | Notice that I use both -O2 and -Os. | Which you shouldn't, unless you don't like glibc.
There was a bug last year that would kill your glibc if you built it with two -O flags in your CFLAGS. Whjo's to know when that will happen again? You're a brave man. | Hmm, that's a serious bug. Basically I want -Os, but I know there are many ebuilds that do not recognize it is actually _more conservative_ than -O2 and thus filter it out. Hence all the previous -O2 and all the -fno options that follow...
man gcc wrote: | -Os Optimize for size. -Os enables all -O2 optimizations that do not
typically increase code size. It also performs further optimiza-
tions designed to reduce code size.
-Os disables the following optimization flags: -falign-functions
-falign-jumps -falign-loops -falign-labels -freorder-blocks
-fprefetch-loop-arrays
If you use multiple -O options, with or without level numbers, the
last such option is the one that is effective. |
Last edited by Gherald on Thu May 05, 2005 9:56 am; edited 1 time in total |
|
Back to top |
|
|
kimchi_sg Advocate
Joined: 26 Nov 2004 Posts: 2968
|
Posted: Thu May 05, 2005 9:51 am Post subject: |
|
|
Gherald wrote: | Basically I want -Os, ... it is actually _more conservative_ than -O2 |
Strictly speaking, this is not true.
man gcc wrote: | -Os
Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size. |
|
|
Back to top |
|
|
Gherald Veteran
Joined: 23 Aug 2004 Posts: 1399 Location: CLUAConsole
|
Posted: Thu May 05, 2005 9:59 am Post subject: |
|
|
kimchi_sg wrote: | Gherald wrote: | Basically I want -Os, ... it is actually _more conservative_ than -O2 |
Strictly speaking, this is not true.
man gcc wrote: | -Os
Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size. |
|
Based on other explanations I've read about what -Os does, I feel confident in saying it is _more conservative_ than -O2 even though it is not strictly a subset of -O2. |
|
Back to top |
|
|
superstoned Guru
Joined: 17 Dec 2004 Posts: 432
|
Posted: Thu May 05, 2005 12:45 pm Post subject: |
|
|
Gherald wrote: | codergeek42 wrote: | You don't need to add those though. The proper MMX/SSE/3DNow! options are implied by your "-march=" setting. | I do not understand why some people think there is a reason to not use flags which are already implied by a previous flag. Ebuilds, particularly poorly written ones, might filter out a general flag like -march but leave something like -mmmx intact.
Notice that I use both -O2 and -Os. |
if an ebuild filters something out, there might be a reason for that... why do you want to break your system? |
|
Back to top |
|
|
nxsty Veteran
Joined: 23 Jun 2004 Posts: 1556 Location: .se
|
Posted: Thu May 05, 2005 12:51 pm Post subject: |
|
|
Gherald wrote: | kimchi_sg wrote: | Gherald wrote: | Basically I want -Os, ... it is actually _more conservative_ than -O2 |
Strictly speaking, this is not true.
man gcc wrote: | -Os
Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size. |
|
Based on other explanations I've read about what -Os does, I feel confident in saying it is _more conservative_ than -O2 even though it is not strictly a subset of -O2. |
-Os disables some -O2 optimization but also turns on other. Something that compiles with -O2 might break with -Os, perl for example. |
|
Back to top |
|
|
Gherald Veteran
Joined: 23 Aug 2004 Posts: 1399 Location: CLUAConsole
|
Posted: Thu May 05, 2005 12:57 pm Post subject: |
|
|
superstoned wrote: | Gherald wrote: | codergeek42 wrote: | You don't need to add those though. The proper MMX/SSE/3DNow! options are implied by your "-march=" setting. | I do not understand why some people think there is a reason to not use flags which are already implied by a previous flag. Ebuilds, particularly poorly written ones, might filter out a general flag like -march but leave something like -mmmx intact.
Notice that I use both -O2 and -Os. |
if an ebuild filters something out, there might be a reason for that... why do you want to break your system? |
You don't understand. Let's use a contrived example.
Suppose "-superflag" enables optimizations -fA, -fB, and -fC and "-lesserflag" only enables optimization -fA.
Thus, compiling a package with "-superflag -lesserflag" enables -fA,-fB,-fC. Compiling a package with only "-superflag" does the same thing.
Now suppose there is an ebuild that needs to disable -fB and -fC, but doesn't care about -fA. The correct way to deal with this would be to append -fnoB and -fnoC to the end of CFLAGS (after -superflag). For simplicity, an ebuild might simply filter out -superflag. But what about -fA? If CFLAGS still contains "-lesserflag", it will be enabled.
Now obviously there would never be a "-lesserflag" that only enables one thing (-fA) but this isn't meant to be a real example. |
|
Back to top |
|
|
superstoned Guru
Joined: 17 Dec 2004 Posts: 432
|
Posted: Thu May 05, 2005 1:29 pm Post subject: |
|
|
Gherald wrote: | superstoned wrote: | Gherald wrote: | codergeek42 wrote: | You don't need to add those though. The proper MMX/SSE/3DNow! options are implied by your "-march=" setting. | I do not understand why some people think there is a reason to not use flags which are already implied by a previous flag. Ebuilds, particularly poorly written ones, might filter out a general flag like -march but leave something like -mmmx intact.
Notice that I use both -O2 and -Os. |
if an ebuild filters something out, there might be a reason for that... why do you want to break your system? |
You don't understand. Let's use a contrived example.
Suppose "-superflag" enables optimizations -fA, -fB, and -fC and "-lesserflag" only enables optimization -fA.
Thus, compiling a package with "-superflag -lesserflag" enables -fA,-fB,-fC. Compiling a package with only "-superflag" does the same thing.
Now suppose there is an ebuild that needs to disable -fB and -fC, but doesn't care about -fA. The correct way to deal with this would be to append -fnoB and -fnoC to the end of CFLAGS (after -superflag). For simplicity, an ebuild might simply filter out -superflag. But what about -fA? If CFLAGS still contains "-lesserflag", it will be enabled.
Now obviously there would never be a "-lesserflag" that only enables one thing (-fA) but this isn't meant to be a real example. |
so, you say there are ebuilds that unnecesair filter certain flags. and, altough its very likely they also don't filter certain flags they should if you try to pass around this, you take the risk. well, i hope the dev's don't mind the bugreports... |
|
Back to top |
|
|
kimchi_sg Advocate
Joined: 26 Nov 2004 Posts: 2968
|
Posted: Thu May 05, 2005 1:33 pm Post subject: |
|
|
Gherald wrote: | superstoned wrote: | if an ebuild filters something out, there might be a reason for that... why do you want to break your system? |
You don't understand. Let's use a contrived example.
Suppose "-superflag" enables optimizations -fA, -fB, and -fC and "-lesserflag" only enables optimization -fA.
Thus, compiling a package with "-superflag -lesserflag" enables -fA,-fB,-fC. Compiling a package with only "-superflag" does the same thing.
Now suppose there is an ebuild that needs to disable -fB and -fC, but doesn't care about -fA. The correct way to deal with this would be... |
... to understand exactly why the ebuild does this, before even considering dangerous things like flag redundancy.
Don't you think that he already understands the mechanics what you're trying to do?
Apparently, it's you who doesn't understand why we are trying to wean you off flag redundancy. Please do not assume those who wrote the ebuilds are villains who wish to block the way to the Great Treasure Trove of Speed. They do think for the health of your system.
Last edited by kimchi_sg on Thu May 05, 2005 1:36 pm; edited 1 time in total |
|
Back to top |
|
|
Gherald Veteran
Joined: 23 Aug 2004 Posts: 1399 Location: CLUAConsole
|
Posted: Thu May 05, 2005 1:34 pm Post subject: |
|
|
superstoned wrote: | so, you say there are ebuilds that unnecesair filter certain flags. and, altough its very likely they also don't filter certain flags they should if you try to pass around this, you take the risk. | Um, sounds like you've sorta got the idea. But the important thing to realize is that only wrong or poorly written ebuilds will be affected...
Quote: | well, i hope the dev's don't mind the bugreports... |
...so they certainly should not mind. |
|
Back to top |
|
|
superstoned Guru
Joined: 17 Dec 2004 Posts: 432
|
Posted: Thu May 05, 2005 3:13 pm Post subject: |
|
|
Gherald wrote: | superstoned wrote: | so, you say there are ebuilds that unnecesair filter certain flags. and, altough its very likely they also don't filter certain flags they should if you try to pass around this, you take the risk. | Um, sounds like you've sorta got the idea. But the important thing to realize is that only wrong or poorly written ebuilds will be affected...
Quote: | well, i hope the dev's don't mind the bugreports... |
...so they certainly should not mind. |
altough you might be right, i think this way you put an undesirable and unnecesairy burden on the developers. if they choose, for time constraints, to block flags "the easy way", they should be free to do so. don't force them to spend more time on it (unless you want to do it yourself) as they are willing to. they are volunteers! also, any speedgain would be extremely small - so i think they acutally should block flags the easy way, if they want to - let them spend time on more important things, be it gentoorelated or not. |
|
Back to top |
|
|
Thuzle n00b
Joined: 01 Jan 2005 Posts: 3 Location: Orford, NH
|
Posted: Wed May 11, 2005 3:06 am Post subject: |
|
|
Hey everyone. I managed to read alot of the thread and used it in helping me with my own CFlags and various other things. I wanted to point out a pecularity on my system.
AMD64 using 2005.0 LiveCD 2.6.8 Kernal.
I was bootstraping with CFLAGS="-O2 -march=k8 -mtune=k8 -fomit-frame-pointer -fomit-leaf-frame-pointer -fforce-addr -ftracer -falign-functions=64 -fprefetch-loop-arrays -freorder-blocks -pipes -m64"
USE="nptl amd64 and the usual except for PIC"
So the bootstrap came to gettext and had an error regarding requiring -fPIC for something, not sure why, but I put it in for that compile and it worked from there on out.
Thought you might like to hear about a problem from NOT having a CFLAG rather then having too many. |
|
Back to top |
|
|
rhill Retired Dev
Joined: 22 Oct 2004 Posts: 1629 Location: sk.ca
|
Posted: Wed May 11, 2005 6:36 am Post subject: |
|
|
i think i read that error is caused by -fprefetch-loop-arrays, but i'm not sure. it's never a good idea to put PIC/PIE flags in make.conf - but i guess in this case it worked .
anyone using machine options other than -march (or -m32 / -m64 i guess) doesn't know what they're doing. not only are they redundant, they're often broken. this goes double for -mfpmath, which never worked properly until gcc4 (and still doesn't on some archs =P). yes some ebuilds filter -march. they do that rarely and specifically because the code breaks when using compiled using an arch-specific instruction set. for example, the most common filtering you'll see is changing pentium4 to pentium3. this is done because the code has been proven to break with sse2. going ahead and forcing that instruction set is kind of a retarded idea, don't you think? _________________ by design, by neglect
for a fact or just for effect |
|
Back to top |
|
|
nxsty Veteran
Joined: 23 Jun 2004 Posts: 1556 Location: .se
|
Posted: Wed May 11, 2005 8:22 am Post subject: |
|
|
Thuzle:
You should neve put -m64 in your CFLAGS. 64bit is already the default on x86_64 and forcing it on like that breaks several ebuilds that needs to compile some parts 32bit. Also remove amd64 from your USE, portage will set that flag itself when necessary. |
|
Back to top |
|
|
|