At 12:29 PM 2/14/2006, Oliver Fromme wrote:
Vinny Abello <[EMAIL PROTECTED]> wrote:
> Oliver Fromme wrote:
> > Vinny Abello <[EMAIL PROTECTED]> wrote:
> > > CFLAGS= -O2 -pipe
> > > COPTFLAGS= -O -pipe
> >
> > I recommend not to overide those two at all. Especially
> > your CFLAGS setting might generate broken code because
> > there are sources which are not aliasing-clean, which can
> > break with any optimizations beyond -O, unless you also
> > specify -fno-strict-aliasing.
>
> Really? Are there any current examples of such? I've never run into
> this myself, but I'm sure you wouldn't be recommending it if it
wasn't true.
XEmacs, PostgreSQL, freetype2 and others. Whether you get
problems or not depends on a lot of things. If you're
lucky, it works. On platforms with only few registers
(like i386) it's more likely to work, because gcc has less
possibilities to exploit aliasing optimizations.
> What about -funroll-loops and -ffast-math? I see a lot of people
> using those options in general as well.
You can use them. They shouldn't cause harm, but in many
cases -funroll-loops makes the code slower, because it
increases the size of the code so it decreases the efficiency
of the processor caches.
> I actually found one reference from someone claiming -O3 is good in
> CFLAGS and -O2 for COPTFLAGS although I have read a lot of things
> about why not to use -O3 in CFLAGS and that it's not supported at all
> with buildworld, so I'm not really interested in using that at all,
> even with ports.
I probably didn't explain it clearly enough. You can use
-O2 (and probably also -O3, but I haven't tried that).
In former times, the gcc optimizer was known to have bugs
that could cause bad code to be generated. As far as I
know, those bugs have been fixed in current versions of
gcc.
However, -O2 also includes -fstrict-aliasing. Strict ali-
asing enables a special optimization which lets the compiler
assume that pointers with incompatible types never point
to the same target. For example, in the function
void func (int *foo, short *bar)
it is legal for the compiler (according to ANSI C) to assume
that the two pointers may not alias. But a lot of programs
don't fulfill that assumption. It's a problem with those
sources, not with gcc.
Therefore the default CFLAGS include -fno-strict-aliasing,
which disables that kind of optimizations in gcc. With
that option, gcc always assumes that pointers may alias.
If you override CFLAGS in your /etc/make.conf by specifying
-O2 (or -O3 or -Os) but not also specifying -fno-strict-ali-
asing, you run the risk of enabling bugs in programs.
> > The defaults are "-O2 -fno-strict-aliasing -pipe" for
> > CFLAGS, and for COPTFLAGS it's "-O -pipe" if DEBUG is
> > defined (the default in GENERIC), otherwise "-O2 -pipe
> > -fno-strict-aliasing".
>
> Is -O2 safe on COPTFLAGS if you have debugging disabled in the
> KERNCONF?
Yes, I think so. But when you disable DEBUG, then -O2 is
the default anyway ("-O2 -pipe -fno-strict-aliasing", to be
exact), so there's no point in overriding it in make.conf.
That's the reason why I recommend not to mess with CFLAGS
and COPTFLAGS in /etc/make.conf. The defaults provided by
the FreeBSD developers are usually the best optimization
possible without creating potentially broken binaries.
Best regards
Oliver
Thanks for all of your excellent explanations, Oliver. Highly appreciated. :)
Vinny Abello
Network Engineer
Server Management
[EMAIL PROTECTED]
(973)300-9211 x 125
(973)940-6125 (Direct)
PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A
Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com (888)TELLURIAN
"Courage is resistance to fear, mastery of fear - not absence of
fear" -- Mark Twain
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
