Learning about Control of Optimization -- for dummies please
Johan at double-l.nl
Wed Aug 5 13:21:17 UTC 2009
>> On Wed, 5 Aug 2009 12:19:23 +0200 Roland Smith
<rsmith at xs4all.nl>
>> >On Wed, Aug 05, 2009 at 10:54:07AM +0100, David Southwell wrote:
>> >> I have found
>> >> http://docs.freebsd.org/info/gcc/gcc.info.Optimize_Options.html.
>> >> I am about to build a new kernel am starting to dig a bit deeper
>> >> things I have, until now, taken for granted.
>> >> The above link is very informative in technical terms about how to
>> >> control optimization but I find it difficult to interpret the info
>> >> way that tells me what might work best on my own system (Intel
>> >> Core) with 8G of ram.
>> >The build system takes care of that, once you have set the correct
>> >CPUTYPE in /etc/make.conf. For a quad-core, set CPUTYPE=nocona. See
>> >make.conf(5), /usr/src/share/mk/bsd.cpu.mk and
>> As I read the man page for [g]cc, though, setting -march=nocona
>> is where the CPUTYPE information ends up in the cc commands) tells
>> compiler which base instruction set to use and which model of
>> scheduling to use, but to get the rest of the model-dependent
>> used, he would still need to add "-mmmx -msse -msse2 -msse3" at a
>> for most other compilations, though these would not be advisable for
>> compilations. I don't recall whether SSE4 instructions are in the
>> Merom/Kentfield chips or first appear in the Core i7 series. I don't
>> the compiler versions available under FreeBSD support the SSE4
>> instructions, though, so SSE4 doesn't matter anyway.
>> >Additionally, compiler settings for building the kernel can be set
>> >COPTFLAGS in /etc/make.conf. Using anything other than -O or -O2 is
>> >not guaranteed to work. If you don't know what you are doing, do not
>> >COPTFLAGS and stick with the defaults that the build system
>> Right. -O3 might royally screw a kernel in particular. :-)
>> Scott Bennett, Comm. ASMELG, CFIAG
>Thanks for add more useful info however would you mind elaborating a
>more because I do not understand the implications.
>should I have:
>Do I need anything else in make.conf?
>So far my draft make.conf has these entries:
>CFLAGS= -O2 -fno-strict-aliasing -pipe
>Incidentally I am also puzzled because it appears necessary to use
>GENERIC as my starting point when the cpu is actually Intel Quad Core!!
>I presume this means that in drafting a kernconf I need to refer to;
>dns1# ls -l
>-rw-r--r-- 1 root wheel 13 Jun 20 2005 .cvsignore
>-rw-r--r-- 1 root wheel 482 Apr 15 04:14 DEFAULTS
>-rw-r--r-- 1 root wheel 11968 Apr 15 04:14 GENERIC
>-rw-r--r-- 1 root wheel 818 Apr 15 04:14 GENERIC.hints
>-rw-r--r-- 1 root wheel 1036 Apr 15 04:14 MAC
>-rw-r--r-- 1 root wheel 132 Apr 15 04:14 Makefile
>-rw-r--r-- 1 root wheel 20721 Apr 15 04:14 NOTES
>It would be great if some logical consistency could be introduced into
>conventions!!! It would really help those of us who know little and
make it a
>trifle easier to climb the greasy pole of knowledge <chuckles>
It is logical.
You use i386 on old amd processors also.
The naming amd64 comes from the fact that AMD did come first with the 64
If Intel was the first it proberly would have a name like i386_64 or
something like that.
Nothing to worry about.
If your Intel proccessor has 64 bit support use the AMD64 version
It is just a name.
About the make.conf the use of nocona is ok but put a ? mark ofter
Do not ask me why, people told me it is better, if i understand
correctly It has someting to do about the choice the compiler has while
building, it could override the nocona setting if it is needed.
If i recall correct!!!!
I would ditch the CFLAGS, the normal setings ar the same as that line
FORCE_MAKE_JOBS is also ok
No virus found in this outgoing message.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.44/2282 - Release Date:
More information about the freebsd-questions