From owner-freebsd-questions@FreeBSD.ORG Fri Mar 9 05:04:53 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 274A416A404 for ; Fri, 9 Mar 2007 05:04:53 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by mx1.freebsd.org (Postfix) with ESMTP id 01A0713C48D for ; Fri, 9 Mar 2007 05:04:52 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l2954qDo017555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 Mar 2007 21:04:52 -0800 X-Auth-Received: from [192.168.10.41] (c-67-187-172-183.hsd1.ca.comcast.net [67.187.172.183]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l2954pIP008799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Mar 2007 21:04:52 -0800 Message-ID: <45F0EAF2.2010303@u.washington.edu> Date: Thu, 08 Mar 2007 21:04:50 -0800 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.9 (X11/20070122) MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <989294.46444.qm@web34411.mail.mud.yahoo.com> <14989d6e0703081645q9b555b5i26cca0557590e9cd@mail.gmail.com> In-Reply-To: <14989d6e0703081645q9b555b5i26cca0557590e9cd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.8.204933 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __RUS_SUBJ_ALL_UCASE_1251 0, __RUS_SUBJ_ALL_UCASE_KOI8R 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: DEFAULT CFLAGS SETTING X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2007 05:04:53 -0000 Christian Walther wrote: > On 08/03/07, White Hat 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