CPUTYPE?=($amd-fx 8120)

R

rhish

I'm not trying to set CFLAGS, just trying to set the proper CPUTYPE for this processor: AMD FX 8120. I only have one of these, so it's no big deal if it is not "optimized", but if there is a particular CPUTYPE to set for this processor, I would like to. I only need to buildworld, buildkernel, and build ports for this workstation, staying on this workstation. Nothing will ever be for some other architecture, or some other workstation.

So far, the options that look most appropriate are:
Code: 
amdfam10
athlon-fx
(I'm not sure if this is the same FX?) I usually just use Nocona, most of the time I have Core2 proc's processors. But there's a new one with AMD FX 8120.

/usr/share/examples/etc/make.conf:
Code: 
#   Intel x86 architecture:
#       (AMD CPUs)      amdfam10, opteron-sse3, athlon64-sse3, k8-sse3,
#                       opteron, athlon64, athlon-fx, k8, athlon-mp,
#                       athlen-xp, athlon-4, athlon-tbird, athlon, k7,
#                       geode, k6-3, k6-2, k6
then
Code: 
# Additionally the following CPU types are recognized by clang:
#       (AMD CPUs)      bdver2, bdver1, btver2, btver1

And in /usr/share/mk/bsd.cpu.mk:
Code: 
.  if ${CPUTYPE} == "barcelona"
CPUTYPE = amdfam10

Does anyone know for sure what CPUTYPE would be the best standard option? What does native do as an option? What happens if I just leave out CPUTYPE, would it query the processor anyways? Or default to something too generic?
 
I've never set CPUTYPE and I seriously doubt you'll see any improvement if you do set it.
 
Yeah, in any case this will give me an opportunity to find out. I'm going to just comment it out of my usual make.conf file.
 
Remember to blame yourself when it blows up in your face later. Like a month or two from now when you get problems with some ports or whatnot.
 
rhish said:
I only need to buildworld, buildkernel, and build ports for this workstation, staying on this workstation. Nothing will ever be for some other architecture, or some other workstation.
Click to expand...

Use CPUTYPE?=native then, i.e. let the compiler detect your CPU and make the best out of it.

I've been using this for years and have yet to see a problem (there are more than 1000 ports installed on this machine, including things like KDE4, Firefox and Chrome). You can use $COMPILER -march=native -E -v - </dev/null 2>&1 | grep cc1 to see what flags a compiler actually enables. Here's a comparison (for an Intel i7-2620M):

Code: 
>> cc (gcc 4.2.1 as shipped with FreeBSD 9.2)
 /usr/libexec/cc1 -E -quiet -v -D_LONGLONG - -march=core2 -mtune=generic

>> gcc46
 /usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.2/4.6.4/cc1 -E -quiet -v - -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mavx -msse4.2 -msse4.1 -mno-rdrnd -mno-f16c -mno-fsgsbase --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=corei7-avx

>> gcc49
 /usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd9.2/4.9.0/cc1 -E -quiet -v - -march=sandybridge -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -maes -mno-sha -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=sandybridge

>> clang (clang 3.3 as shipped with FreeBSD 9.2)
 "/usr/bin/clang" -cc1 -triple x86_64-unknown-freebsd9.2 -E -disable-free -main-file-name - -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu corei7-avx -v -resource-dir /usr/bin/../lib/clang/3.3 -fdebug-compilation-dir /home/foo -ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gnustep -fobjc-default-synthesize-properties -fdiagnostics-show-option -backend-option -vectorize-loops -o - -x c -
 
Nope, no problems. Everything works as expected.

The (custom) kernel and world are built with clang. Most ports are compiled with gcc46 (which I can't really recommend unless you pretty much know what you're doing and don't mind going through a lot of try and error).
 
You must log in or register to reply here.
Back
Top