Date: Thu, 08 Mar 2007 21:04:50 -0800 From: Garrett Cooper <youshi10@u.washington.edu> To: freebsd-questions@freebsd.org Subject: Re: DEFAULT CFLAGS SETTING Message-ID: <45F0EAF2.2010303@u.washington.edu> In-Reply-To: <14989d6e0703081645q9b555b5i26cca0557590e9cd@mail.gmail.com> References: <989294.46444.qm@web34411.mail.mud.yahoo.com> <14989d6e0703081645q9b555b5i26cca0557590e9cd@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Christian Walther wrote:
> On 08/03/07, White Hat <pigskin_referee@yahoo.com> wrote:
>> What is the default CFLAGS setting in FBSD-6.2 and would it improve
>> performance any to set
>>
>> CFLAGS=Os
>>
>> as opposed to the default setting?
>>
> CFLAGS can be defined in /etc/make.conf
> My CFLAGS is set to -O2 -pipe. You might want to take a look at
> CPUTYPE, too. This can be set to match your CPU type, which means
> you'll get the most of it.
> You can find some examples in /usr/share/examples/etc/make.conf
>
> HTH
> Christian
As mentioned when I asked the question a while back, be careful about
how you "optimize" freebsd. Adding additional options beyond "-O2 -pipe
-fno-strict-aliasing" isn't really supported so much and is discouraged
by many on this list (AFAIK) and a lot of people on the hackers@ list
(that I do know). Unlike some linux distributions where using CFLAGS and
CXXFLAGS are encouraged, it's discouraged here because it generates a
lot more variation in having to check through errors, and many times the
levels of optimization used my system users is counterproductive to the
purpose of optimizing.
I was told to add -fno-strict-aliasing, because it's an option to allow
some programs and code compile that are improperly developed or use
deprecated code / features.
From gcc(1):
-fstrict-aliasing
Allows the compiler to assume the strictest aliasing rules
applicable to the language being compiled. For C (and C++),
this activates optimizations based on the type of
expressions. In particular, an object of one type is assumed
never to reside at the same address as an object of a
different type, unless the types are almost the same. For
example, an "unsigned int" can alias an "int", but not a
"void*" or a "double". A character type may alias any other
type.
Pay special attention to code like this:
union a_union {
int i;
double d;
};
int f() {
a_union t;
t.d = 3.0;
return t.i;
}
The practice of reading from a different union member than
the one most recently written to (called ``type-punning'') is
common. Even with -fstrict-aliasing, type-punning is
allowed, provided the memory is accessed through the union
type. So, the code above will work as expected. However,
this code might not:
int f() {
a_union t;
int* ip;
t.d = 3.0;
ip = &t.i;
return *ip;
}
Every language that wishes to perform language-specific alias
analysis should define a function that computes, given an
"tree" node, an alias set for the node. Nodes in different
alias sets are not allowed to alias. For an example, see the
C front-end function "c_get_alias_set".
Enabled at levels -O2, -O3, -Os.
Just provide inverse logic of the above set of statements.
Definitely set CPUTYPE though--this will help since it gets passed to
gcc as -march=$CPUTYPE. However, since the version of gcc the base
system works with isn't bleeding edge it won't support all processor
types / optimizations available in later versions of gcc. There is an
examples of a make.conf file in /usr/share/etc/make.conf.example.
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45F0EAF2.2010303>