CPUTYPE=native handling
hi there,
i've seen dozens of issues, where people set CPUTYPE=native. although this
works in a lot of cases, it doesn't in others. why don't we simply add
something like
. if ${CPUTYPE} == "native"
. error "bla"
. endif
in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native" is
known to cause problems.
cheers.
alex
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
On 2011-11-08 01:25, Alexander Best wrote:
> i've seen dozens of issues, where people set CPUTYPE=native. although this
> works in a lot of cases, it doesn't in others. why don't we simply add
> something like
>
> . if ${CPUTYPE} == "native"
> . error "bla"
> . endif
>
> in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native" is
> known to cause problems.
What does this solve? Don't you think it is better to try to fix the
actual problems? Some people like being able to optimize for their
specific CPU, however much you can shoot yourself in the foot with it.
I haven't seen any consistent bug reports yet, just a lot of complaints
that indicate a rather high probability of PEBKAC.
And just to counter the nay-saying, I compiled a number of boxes with
clang -march=native (mostly of the Xeon/i7 variant) and I haven't seen
any problems at all.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
On Tue, Nov 08, 2011 at 08:55:39AM +0100, Dimitry Andric wrote:
> On 2011-11-08 01:25, Alexander Best wrote:
> > i've seen dozens of issues, where people set CPUTYPE=native. although this
> > works in a lot of cases, it doesn't in others. why don't we simply add
> > something like
> >
> > . if ${CPUTYPE} == "native"
> > . error "bla"
> > . endif
> >
> > in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native" is
> > known to cause problems.
>
> What does this solve? Don't you think it is better to try to fix the
> actual problems? Some people like being able to optimize for their
Yes, we definitely should aim for fixing the problems instead of working
around them.
This way both clang and freebsd benefits.
roman
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
On Tue Nov 8 11, Roman Divacky wrote:
> On Tue, Nov 08, 2011 at 08:55:39AM +0100, Dimitry Andric wrote:
> > On 2011-11-08 01:25, Alexander Best wrote:
> > > i've seen dozens of issues, where people set CPUTYPE=native. although this
> > > works in a lot of cases, it doesn't in others. why don't we simply add
> > > something like
> > >
> > > . if ${CPUTYPE} == "native"
> > > . error "bla"
> > > . endif
> > >
> > > in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native"
> > > is
> > > known to cause problems.
> >
> > What does this solve? Don't you think it is better to try to fix the
> > actual problems? Some people like being able to optimize for their
>
> Yes, we definitely should aim for fixing the problems instead of working
> around them.
>
> This way both clang and freebsd benefits.
for me -march=native reports:
otaku% gcc -march=native -E -v - search starts here:
/usr/include/gcc/4.2
/usr/include
End of search list.
# 1 ""
# 1 ""
# 1 ""
# 1 ""
where instead of nocona, core2 would have been the better choice:
[1.00] CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1800.00-MHz
K8-class CPU)
[1.00] Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f
Stepping = 13
[1.00]
Features=0xbfebfbff
[1.00]
Features2=0xe39d
[1.00] AMD Features=0x20100800
[1.00] AMD Features2=0x1
[1.00] TSC: P-state invariant, performance statistics
cheers.
alex
>
> roman
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
clang will use "core2" for family=6 and model=15
check llvm/lib/Support/Host.cpp
what is the problem? The fact that our gcc from the middle-ages
does not recognize that?
On Tue, Nov 08, 2011 at 09:04:20PM +, Alexander Best wrote:
> On Tue Nov 8 11, Roman Divacky wrote:
> > On Tue, Nov 08, 2011 at 08:55:39AM +0100, Dimitry Andric wrote:
> > > On 2011-11-08 01:25, Alexander Best wrote:
> > > > i've seen dozens of issues, where people set CPUTYPE=native. although
> > > > this
> > > > works in a lot of cases, it doesn't in others. why don't we simply add
> > > > something like
> > > >
> > > > . if ${CPUTYPE} == "native"
> > > > . error "bla"
> > > > . endif
> > > >
> > > > in share/mk/bsd.cpu.mk for now? or at least for the archs, where
> > > > "native" is
> > > > known to cause problems.
> > >
> > > What does this solve? Don't you think it is better to try to fix the
> > > actual problems? Some people like being able to optimize for their
> >
> > Yes, we definitely should aim for fixing the problems instead of working
> > around them.
> >
> > This way both clang and freebsd benefits.
>
> for me -march=native reports:
>
> otaku% gcc -march=native -E -v - Using built-in specs.
> Target: amd64-undermydesk-freebsd
> Configured with: FreeBSD/amd64 system compiler
> Thread model: posix
> gcc version 4.2.2 20070831 prerelease [FreeBSD]
> /usr/libexec/cc1 -E -quiet -v -D_LONGLONG - -march=nocona -mtune=generic
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/include/gcc/4.2
> /usr/include
> End of search list.
> # 1 ""
> # 1 ""
> # 1 ""
> # 1 ""
>
> where instead of nocona, core2 would have been the better choice:
>
> [1.00] CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1800.00-MHz
> K8-class CPU)
> [1.00] Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f
> Stepping = 13
> [1.00]
> Features=0xbfebfbff
> [1.00]
> Features2=0xe39d
> [1.00] AMD Features=0x20100800
> [1.00] AMD Features2=0x1
> [1.00] TSC: P-state invariant, performance statistics
>
> cheers.
> alex
>
> >
> > roman
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
On Tue Nov 8 11, Roman Divacky wrote:
> clang will use "core2" for family=6 and model=15
>
> check llvm/lib/Support/Host.cpp
>
> what is the problem? The fact that our gcc from the middle-ages
> does not recognize that?
actually a few months ago quite a lot of gcc commits happend to add newer
optimisations (such as core2) to gcc and some commits aimed at modifying gcc,
so it would make the best -march=native choice there is.
what's the clang command (similar to gcc -march=native -E -v - http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/84800
and
http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg161451.html
cheers.
alex
>
> On Tue, Nov 08, 2011 at 09:04:20PM +, Alexander Best wrote:
> > On Tue Nov 8 11, Roman Divacky wrote:
> > > On Tue, Nov 08, 2011 at 08:55:39AM +0100, Dimitry Andric wrote:
> > > > On 2011-11-08 01:25, Alexander Best wrote:
> > > > > i've seen dozens of issues, where people set CPUTYPE=native. although
> > > > > this
> > > > > works in a lot of cases, it doesn't in others. why don't we simply add
> > > > > something like
> > > > >
> > > > > . if ${CPUTYPE} == "native"
> > > > > . error "bla"
> > > > > . endif
> > > > >
> > > > > in share/mk/bsd.cpu.mk for now? or at least for the archs, where
> > > > > "native" is
> > > > > known to cause problems.
> > > >
> > > > What does this solve? Don't you think it is better to try to fix the
> > > > actual problems? Some people like being able to optimize for their
> > >
> > > Yes, we definitely should aim for fixing the problems instead of working
> > > around them.
> > >
> > > This way both clang and freebsd benefits.
> >
> > for me -march=native reports:
> >
> > otaku% gcc -march=native -E -v - > Using built-in specs.
> > Target: amd64-undermydesk-freebsd
> > Configured with: FreeBSD/amd64 system compiler
> > Thread model: posix
> > gcc version 4.2.2 20070831 prerelease [FreeBSD]
> > /usr/libexec/cc1 -E -quiet -v -D_LONGLONG - -march=nocona -mtune=generic
> > #include "..." search starts here:
> > #include <...> search starts here:
> > /usr/include/gcc/4.2
> > /usr/include
> > End of search list.
> > # 1 ""
> > # 1 ""
> > # 1 ""
> > # 1 ""
> >
> > where instead of nocona, core2 would have been the better choice:
> >
> > [1.00] CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz
> > (1800.00-MHz K8-class CPU)
> > [1.00] Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f
> > Stepping = 13
> > [1.00]
> > Features=0xbfebfbff
> > [1.00]
> > Features2=0xe39d
> > [1.00] AMD Features=0x20100800
> > [1.00] AMD Features2=0x1
> > [1.00] TSC: P-state invariant, performance statistics
> >
> > cheers.
> > alex
> >
> > >
> > > roman
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
On Tue, Nov 08, 2011 at 09:23:52PM +, Alexander Best wrote: > On Tue Nov 8 11, Roman Divacky wrote: > > clang will use "core2" for family=6 and model=15 > > > > check llvm/lib/Support/Host.cpp > > > > what is the problem? The fact that our gcc from the middle-ages > > does not recognize that? > > actually a few months ago quite a lot of gcc commits happend to add newer > optimisations (such as core2) to gcc and some commits aimed at modifying gcc, > so it would make the best -march=native choice there is. > > what's the clang command (similar to gcc -march=native -E -v - one can use to check what actual optimisation clang turns "native" into? clang -### -march=native will show something like "-target-cpu" "k8-sse3" > also there seem to be cross-compilation issues. when people are running i386 > and want to cross-compile for amd64 and put CPUTYPE=core2 (or any other amd64 > cpu) into their make.conf, this gets downgraded by bsd.cpu.mk to prescott. > > see http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/84800 > and > http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg161451.html If gcc supports nocona now, the conf/84800 patch is ok. The same goes with downgrading core2 -> prescott. I have no idea what gcc supports these days. I think we should just skip the downgrading completely for clang as it either supports everything or can be made easily to support what it doesnt. roman ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
On Tue Nov 8 11, Roman Divacky wrote: > On Tue, Nov 08, 2011 at 09:23:52PM +, Alexander Best wrote: > > On Tue Nov 8 11, Roman Divacky wrote: > > > clang will use "core2" for family=6 and model=15 > > > > > > check llvm/lib/Support/Host.cpp > > > > > > what is the problem? The fact that our gcc from the middle-ages > > > does not recognize that? > > > > actually a few months ago quite a lot of gcc commits happend to add newer > > optimisations (such as core2) to gcc and some commits aimed at modifying > > gcc, > > so it would make the best -march=native choice there is. > > > > what's the clang command (similar to gcc -march=native -E -v - > one can use to check what actual optimisation clang turns "native" into? > > clang -### -march=native will show something like otaku% clang -### -march=native FreeBSD clang version 3.0 (trunk 135360) 20110717 Target: x86_64-unknown-freebsd9.0 Thread model: posix ? > > "-target-cpu" "k8-sse3" > > > > also there seem to be cross-compilation issues. when people are running i386 > > and want to cross-compile for amd64 and put CPUTYPE=core2 (or any other > > amd64 > > cpu) into their make.conf, this gets downgraded by bsd.cpu.mk to prescott. > > > > see http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/84800 > > and > > http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg161451.html > > If gcc supports nocona now, the conf/84800 patch is ok. The same goes > with downgrading core2 -> prescott. > > I have no idea what gcc supports these days. I think we should just skip > the downgrading completely for clang as it either supports everything or > can be made easily to support what it doesnt. > > roman ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
On 2011-11-08 22:04, Alexander Best wrote:
...
> for me -march=native reports:
>
> otaku% gcc -march=native -E -v - Using built-in specs.
> Target: amd64-undermydesk-freebsd
> Configured with: FreeBSD/amd64 system compiler
> Thread model: posix
> gcc version 4.2.2 20070831 prerelease [FreeBSD]
> /usr/libexec/cc1 -E -quiet -v -D_LONGLONG - -march=nocona -mtune=generic
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/include/gcc/4.2
> /usr/include
> End of search list.
> # 1 ""
> # 1 ""
> # 1 ""
> # 1 ""
>
> where instead of nocona, core2 would have been the better choice:
>
> [1.00] CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1800.00-MHz
> K8-class CPU)
> [1.00] Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f
> Stepping = 13
> [1.00]
> Features=0xbfebfbff
> [1.00]
> Features2=0xe39d
> [1.00] AMD Features=0x20100800
> [1.00] AMD Features2=0x1
> [1.00] TSC: P-state invariant, performance statistics
That's weird, the logic in gcc goes:
cpuid (1, eax, ebx, ecx, edx);
...
has_ssse3 = !!(ecx & bit_SSSE3);
...
if (arch)
{
if (has_ssse3)
cpu = "core2";
else if (has_sse3)
{
if (has_longmode)
cpu = "nocona";
else
cpu = "prescott";
}
else if (has_sse2)
cpu = "pentium4";
else if (has_cmov)
cpu = "pentiumpro";
else if (has_mmx)
cpu = "pentium-mmx";
else if (has_cmpxchg8b)
cpu = "pentium";
else
cpu = "i386";
}
else
cpu = "generic";
goto done;
E.g. it seems to conclude your cpu *doesn't* have SSSE3, but does have
long mode, and thus jumps to nocona.
You might be able to debug this, by putting some printfs in this
function. :)
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
On Tue, Nov 08, 2011 at 12:25:56AM +, Alexander Best wrote: > hi there, > > i've seen dozens of issues, where people set CPUTYPE=native. although this > works in a lot of cases, it doesn't in others. why don't we simply add > something like I thought it was reccomened to use 'CPUTYPE?=' syntax therefore ultimately allowing the build to omit the CPUTYPE for its own setting... since not all optimizations done for -march or -mcpu are good for the whole source tree. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
On Tue Nov 8 11, Dimitry Andric wrote:
> On 2011-11-08 22:04, Alexander Best wrote:
> ...
> > for me -march=native reports:
> >
> > otaku% gcc -march=native -E -v - > Using built-in specs.
> > Target: amd64-undermydesk-freebsd
> > Configured with: FreeBSD/amd64 system compiler
> > Thread model: posix
> > gcc version 4.2.2 20070831 prerelease [FreeBSD]
> > /usr/libexec/cc1 -E -quiet -v -D_LONGLONG - -march=nocona -mtune=generic
> > #include "..." search starts here:
> > #include <...> search starts here:
> > /usr/include/gcc/4.2
> > /usr/include
> > End of search list.
> > # 1 ""
> > # 1 ""
> > # 1 ""
> > # 1 ""
> >
> > where instead of nocona, core2 would have been the better choice:
> >
> > [1.00] CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz
> > (1800.00-MHz K8-class CPU)
> > [1.00] Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f
> > Stepping = 13
> > [1.00]
> > Features=0xbfebfbff
> > [1.00]
> > Features2=0xe39d
> > [1.00] AMD Features=0x20100800
> > [1.00] AMD Features2=0x1
> > [1.00] TSC: P-state invariant, performance statistics
>
> That's weird, the logic in gcc goes:
>
> cpuid (1, eax, ebx, ecx, edx);
> ...
> has_ssse3 = !!(ecx & bit_SSSE3);
> ...
> if (arch)
> {
> if (has_ssse3)
> cpu = "core2";
> else if (has_sse3)
> {
> if (has_longmode)
> cpu = "nocona";
> else
> cpu = "prescott";
> }
> else if (has_sse2)
> cpu = "pentium4";
> else if (has_cmov)
> cpu = "pentiumpro";
> else if (has_mmx)
> cpu = "pentium-mmx";
> else if (has_cmpxchg8b)
> cpu = "pentium";
> else
> cpu = "i386";
> }
> else
> cpu = "generic";
> goto done;
>
> E.g. it seems to conclude your cpu *doesn't* have SSSE3, but does have
> long mode, and thus jumps to nocona.
>
> You might be able to debug this, by putting some printfs in this
> function. :)
same on ref9-amd64.freebsd.org:
ref9-amd64% clang -march=native -### blabla.c
FreeBSD clang version 3.0 (trunk 135360) 20110717
Target: x86_64-unknown-freebsd9.0
Thread model: posix
"/usr/bin/clang" "-cc1" "-triple" "x86_64-unknown-freebsd9.0" "-emit-obj"
"-mrelax-all" "-disable-free" "-main-file-name" "tower.c" "-mrelocation-model"
"static" "-mdisable-fp-elim" "-masm-verbose" "-mconstructor-aliases"
"-munwind-tables" "-target-cpu" "core2" "-momit-leaf-frame-pointer"
"-resource-dir" "/usr/bin/../lib/clang/3.0" "-ferror-limit" "19"
"-fmessage-length" "275" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o"
"/tmp/cc-ImChyq.o" "-x" "c" "tower.c"
"/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "-o"
"tower" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib"
"/tmp/cc-ImChyq.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc"
"-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o"
"/usr/lib/crtn.o"
BUT
ref9-amd64% gcc -march=native -E -v - search starts here:
/usr/include/gcc/4.2
/usr/include
End of search list.
# 1 ""
# 1 ""
# 1 ""
# 1 ""
cheers.
alex
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
On Tue Nov 8 11, Dimitry Andric wrote:
> On 2011-11-08 01:25, Alexander Best wrote:
> > i've seen dozens of issues, where people set CPUTYPE=native. although this
> > works in a lot of cases, it doesn't in others. why don't we simply add
> > something like
> >
> > . if ${CPUTYPE} == "native"
> > . error "bla"
> > . endif
> >
> > in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native" is
> > known to cause problems.
>
> What does this solve? Don't you think it is better to try to fix the
> actual problems? Some people like being able to optimize for their
> specific CPU, however much you can shoot yourself in the foot with it.
just wanted to report that i found an issue with CPUTYPE "native". simply do
the following on amd64 (i tested this on ref9-amd64.freebsd.org):
make.conf:
CPUTYPE ?= native
CFLAGS = -O2 -pipe -fno-strict-aliasing -funroll-loops -fno-builtin
KERNCONF = GENERIC
now 'make buildworld' and enjoy the signal 11. ;)
setting CPUTYPE to nocona or commenting it out lets 'mak buildworld' succeed.
cheers.
alex
there's a problem report for this already:
http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/149712
>
> I haven't seen any consistent bug reports yet, just a lot of complaints
> that indicate a rather high probability of PEBKAC.
>
> And just to counter the nay-saying, I compiled a number of boxes with
> clang -march=native (mostly of the Xeon/i7 variant) and I haven't seen
> any problems at all.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
