CFLAGS Central (Part 2)

[Drysh]

Has anyone tested these two:

-frename-registers
-funit-at-a-time

I'm using them without any problem, but I would like to know what you think. The full line is:

CFLAGS="-march=pentium4m -O3 -pipe -fomit-frame-pointer -fno-ident -msse2 -falign-functions=4 -frename-registers -funit-at-a-time -mfpmath=sse"

[moocha]

Has anyone tested these two:

-frename-registers
-funit-at-a-time

I'm using them without any problem, but I would like to know what you think. The full line is:

CFLAGS="-march=pentium4m -O3 -pipe -fomit-frame-pointer -fno-ident -msse2 -falign-functions=4 -frename-registers -funit-at-a-time -mfpmath=sse"

-frename-registers is already implied by -O3, and -funit-at-a-time is already implied by -O2, hence also by -O3. -frename-registers is not a good idea - it increases compile time considerably (up to 30% more compile time, depending on the code being compiled) and it produces no measurable speedups on IA32 architectures since IA32 is very register-starved. In the past it was also the cause for a lot of bugs due to invalid code being produced, and it's being dropped from the -O set of overall flags in the 4.x GCC line, AFAIK. I'd turn it off explicitely if you insist on -O3, by adding -fno-rename-registers.
So in short drop those two flags, they're pointless.

[rovingtarget]

Even though I use -O2, I keep -funit-at-a-time around simply because it's one of the best CFLAGS and it never hurts to use a flag that is implied by another flag. Ebuilds may filter out -O2 for other reasons yet leave -funit-at-a-time alone.

[Satori80]

I could use a little advice here. From what I understand GCC reads the last similar option as overriding the any previous similar flags. So if one were to put “-mtune=athlon-xp -march=athlon-xp” the -march flag should be used unless the ebuild filters out the -march flag, in which case the -mtune flag should be used. Correct?

If this is the case, why when I rebuild glibc are the flags switched to “-march=athlon-xp -mtune=athlon-xp”? Does this tune for athlon-xp rather than build for athlon-xp?

[bambam_]

I could use a little advice here. From what I understand GCC reads the last similar option as overriding the any previous similar flags. So if one were to put “-mtune=athlon-xp -march=athlon-xp” the -march flag should be used unless the ebuild filters out the -march flag, in which case the -mtune flag should be used. Correct?

If this is the case, why when I rebuild glibc are the flags switched to “-march=athlon-xp -mtune=athlon-xp”? Does this tune for athlon-xp rather than build for athlon-xp?

The only flags I know of (asside from the obvious -fno-* flags) that disable previous flags are of the -O variety, for which the last -O flag specified takes effect.

[Satori80]

Not so, because if you put -w (suppress warnings) before -Wall (print all warnings) you will see all warnings are printed. If it's the other way around the warning messages are suppressed. Each switch that conflicts with another switch in your CFLAGS should supersede the one before it. I don't know if -mtune conflicts with -march, but I guess -march is supposed to imply -mtune anyway so it's probably irrelevant where it comes in unless, as I suggested previously, the ebuild filters out the -march switch.

I was just curious if anyone knows for sure.

[bambam_]

Not so, because if you put -w (suppress warnings) before -Wall (print all warnings) you will see all warnings are printed.

Um, well I was refering to flags that actually affect the code generated.

[rafaelkafka]

I have a pentium 3. I am using this line:

CFLAGS="-march=pentium3 -O3 -fomit-frame-pointer -momit-leaf-frame-pointer -pipe -ffast-math -fno-ident -fforce-addr -falign-functions=4 -fprefetch-loop-arrays"

Are they good flags?

Thank you

Rafael Kafka

[codergeek42]

-O3

Use "-O2" or "-Os" instead, since -O3 usually makes code actually go slower on x86 (which is due to its lack of many available registers).

-momit-leaf-frame-pointer

That's implied by "-fomit-frame-pointer" if I recall correctly.

-ffast-math

That breaks things. Don't use it.

[Bartlet]

-O3

Use "-O2" or "-Os" instead, since -O3 usually makes code actually go slower on x86 (which is due to its lack of many available registers).

-frename-registers slows code compilation, not code exectution (which it can still theoretically improve, even on x86)

-momit-leaf-frame-pointer

That's implied by "-fomit-frame-pointer" if I recall correctly.

You recall incorrectly.

-ffast-math

That breaks things. Don't use it.

It helps more than it hurts, but its not worth the hassle because of the packages you need to disable it for... Something to put on the backburner until package-specific cflags becomes friendlier.

[nxsty]

-frename-registers slows code compilation, not code exectution (which it can still theoretically improve, even on x86)

-O3 also includes -finline-functions which causes unnecessary bloat in binaries which might make them execute slower. So -O2 is generally a better choice than -O3. -O3 should only be used for cpu intensive stuff, not everything.

You recall incorrectly.

It's true that -fomit-frame-pointer doesn't include -momit-leaf-frame-pointer. But they are useless togheter since -momit-leaf-frame-pointer overrides -fomit-frame-pointer. So you will get faster code by just using -fomit-frame-pointer.

[rafaelkafka]

-O3

Use "-O2" or "-Os" instead, since -O3 usually makes code actually go slower on x86 (which is due to its lack of many available registers).

-momit-leaf-frame-pointer

That's implied by "-fomit-frame-pointer" if I recall correctly.

-ffast-math

That breaks things. Don't use it.

Thank you very much!

Rafael Kafka

[augury]

-falign-labels= -falign-loops= are the more wasteful/worthless of the 4. -mtune will generate jumps in the code causing more work and memory use and will not fix poor arch code. the processor will be polled for capabilities and one path will always be followed.

[M1Sports20]

I made a mistake and compiled with CFLAG = -march=i686
i would like to change it to -march=pentium4.
i did this but now how do i get it to take effect in the ebuilds.
im sorry i found the answer on the forums. guess i just didn't look hard enough the first time
answer: emerge -e system && emerge -e world

So I have another question now. It looks like emerge -e world will compile more ebuilds in than i currently have. Would this be true?

[brfsa]

I compiled all my packages with this settings. everything went smooth... no problems...
Even open-office compiled(took more than 10 hours, how insane!)

My insane flags are:

CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -mtune=athlon-xp"
CFLAGS="${CFLAGS} -pipe"
CFLAGS="${CFLAGS} -O3"
CFLAGS="${CFLAGS} -fweb"
CFLAGS="${CFLAGS} -frename-registers"
CFLAGS="${CFLAGS} -fforce-addr"
CFLAGS="${CFLAGS} -momit-leaf-frame-pointer"
CFLAGS="${CFLAGS} -fomit-frame-pointer"
CFLAGS="${CFLAGS} -ftracer"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

I know that some of these flags are already included in -O3, but just wanna keep them there.

Cheers

[codergeek42]

New P4-based system. CFLAGS is as follows:

Code: Select all

CFLAGS="-Os -march=pentium4 -fomit-frame-pointer -pipe -funit-at-a-time"

I've got -funit-at-a-time in there because I'm not sure whether or not it's implied by -Os and the GCC docs aren't exactly fun to read through.

I've found that, at least on my hardware, -Os instead of -O2 seems to create a more responsive and interactive environment. Perhaps it's all pyschological though.

[wyv3rn]

It's true that -fomit-frame-pointer doesn't include -momit-leaf-frame-pointer. But they are useless togheter since -momit-leaf-frame-pointer overrides -fomit-frame-pointer. So you will get faster code by just using -fomit-frame-pointer.

+1. I don't add any flags until I search high and low for what they do any all their drawbacks (thus my global CFLAGS are rather plain). I thought it would be nice to include -momit-leaf-frame-pointer for the packages that filter out -fomit-frame-pointer. I discovered -momit-leaf-frame-pointer actually OVERRIDES -fomit-frame-pointer for whatever reason. This seems illogical, one would think it should be the other way around, but it is not.

Anyone know if there are any stability/runtime correctness drawbacks to -Qn? I haven't found any. Even though the gcc man page says this is the default, that is not true. I've compared executable sizes with and w/o and they are always smaller with -Qn set.

[xordan]

Well I use:

CFLAGS="-march=athlon64 -O2 -pipe"
CXXFLAGS="${CFLAGS}"

which seem quite sensible Is there anything I can add which will give a noticable performance increase, without making things very unstable? I've read through quite a lot, and I haven't seen anything which doesn't either break things or bloat code so there's performance decrease due to that. Is there any point in having anything more than this in my flags?

[nxsty]

Well I use:

CFLAGS="-march=athlon64 -O2 -pipe"
CXXFLAGS="${CFLAGS}"

which seem quite sensible Is there anything I can add which will give a noticable performance increase, without making things very unstable? I've read through quite a lot, and I haven't seen anything which doesn't either break things or bloat code so there's performance decrease due to that. Is there any point in having anything more than this in my flags?

you could add -fvisibility-inlines-hidden to your CXXFLAGS. It has good effect on c++ stuff like KDE, mozilla, Openoffice etc by reducing bloat.

[IvanZD]

Hi!

What flags do you recommend for building a rock stable server? Speed is least important thing; only maximum stability is goal. X86 system.

Thx!

[moocha]

Hi!

What flags do you recommend for building a rock stable server? Speed is least important thing; only maximum stability is goal. X86 system.

Thx!

"x86" doesn't cut it, be a little more specific. But the CFLAGS and CXXFLAGS when aiming for stability over all are always:

Code: Select all

CFLAGS="-march=<yourarch> -mtune=<yourarch> -O2 -fomit-frame-pointer -pipe -fno-ident"
CXXFLAGS="${CFLAGS}"

where you replace <yourarch> by pentium4 if you have a Pentium 4, pentium3 if you have a P3, athlon-xp if you have an Athlon XP, etc etc. For example, for a Pentium 3 system they'd be

Code: Select all

CFLAGS="-march=pentium3 -mtune=pentium3 -O2 -fomit-frame-pointer -pipe -fno-ident"
CXXFLAGS="${CFLAGS}"

Don't add or change anything else - all other flags trade off stability.

[IvanZD]

Code: Select all

CFLAGS="-march=<yourarch> -mtune=<yourarch> -O2 -fomit-frame-pointer -pipe -fno-ident"
CXXFLAGS="${CFLAGS}"

Don't add or change anything else - all other flags trade off stability.

Thx, that was I looking for, but that I am wondering is: will -O1 or even without -O flag give more stable system than -O2 flag? Or I will get only equally stable and slower system?

[nxsty]

Thx, that was I looking for, but that I am wondering is: will -O1 or even without -O flag give more stable system than -O2 flag? Or I will get only equally stable and slower system?

No, -O2 is the stable choice and there is no reason going any lower except if you care about compile times.

[J0sep]

0k, 0k, 0k.... t00 much...

I've installed gentoo as an x86 in a athlon 64 and it is working after a lot of battle, now... i've got to the part after the
#emerge -e system

and #etc-update is also checked

What i would like to know, since (forgive me if i'm wrong!) no one has asked it, when can -march=athlon64 be applied to the CFLAGS 'cause when i was installing I couldn't use any other than -march=i686

After installing and the first reboot, gcc passed to 3.4.4 as gcc-config -l reported, so I applied those 2 commands above.

Now i would able to change the CFLAGS and maybe run a

#emerge -e system
#emerge -e system

maybe?
and what else?


First I want to thank u all in this community it feels like a real family here.
I could get it all done and well only by searching in the forums and reading as much manual and review as i could, and only registered to be part of this and ask this one

[nxsty]

If you have gcc 3.4 you can use -march=athlon64 already. If you want everything compiled with it just do an emerge -e world.