CFLAGS Central (Part 2)

[Maedhros]

Continued from CFLAGS Central (Part 1)

[elvisthedj]

Code: Select all

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: Select all

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

[moocha]

• -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.

[Gherald]

yay, giant thread gone, I can get some personal attention

How's this:

Code: Select all

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?

[elvisthedj]

* -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)

[codergeek42]

You don't need to add those though. The proper MMX/SSE/3DNow! options are implied by your "-march=" setting.

[Gherald]

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.

[elvisthedj]

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

[Gherald]

I thought mplayer ignored most CFLAGS...

[codergeek42]

Yup. That's why it has mmx, mmxext, sse, sse2, 3dnow, and 3dnowext USE flags.

[elvisthedj]

codergeek42 says:

Yup. That's why it has mmx, mmxext, sse, sse2, 3dnow, and 3dnowext USE flags

mplayer's ebuild says:

# 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.

[moocha]

yay, giant thread gone, I can get some personal attention

How's this:

Code: Select all

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.

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...

Ebuilds, particularly poorly written ones, might filter out a general flag like -march but leave something like -mmmx intact.

And might break horribly.

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?

[Gherald]

Code: Select all

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.

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: Select all

#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.

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...

-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.

[kimchi_sg]

Basically I want -Os, ... it is actually _more conservative_ than -O2

Strictly speaking, this is not true.

-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.

[Gherald]

Basically I want -Os, ... it is actually _more conservative_ than -O2

Strictly speaking, this is not true.

-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.

[superstoned]

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?

[nxsty]

Basically I want -Os, ... it is actually _more conservative_ than -O2

Strictly speaking, this is not true.

-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.

[Gherald]

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.

[superstoned]

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...

[kimchi_sg]

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.

[Gherald]

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...

well, i hope the dev's don't mind the bugreports...

...so they certainly should not mind.

[superstoned]

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...

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.

[Thuzle]

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.

[rhill]

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?

[nxsty]

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.