From owner-freebsd-toolchain@FreeBSD.ORG Tue Nov 8 21:23:52 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 93F9D106566B; Tue, 8 Nov 2011 21:23:52 +0000 (UTC) Date: Tue, 8 Nov 2011 21:23:52 +0000 From: Alexander Best To: Roman Divacky Message-ID: <20111108212352.GA39160@freebsd.org> References: <20111108002556.GA91218@freebsd.org> <4EB8E07B.5070908@FreeBSD.org> <20111108153856.GA90966@freebsd.org> <20111108210420.GA37161@freebsd.org> <20111108210905.GA28416@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111108210905.GA28416@freebsd.org> Cc: freebsd-toolchain@freebsd.org, Dimitry Andric Subject: Re: CPUTYPE=native handling X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 21:23:52 -0000 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 - > On Tue, Nov 08, 2011 at 09:04:20PM +0000, 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.000000] CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1800.00-MHz K8-class CPU) > > [1.000000] Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 > > [1.000000] Features=0xbfebfbff > > [1.000000] Features2=0xe39d > > [1.000000] AMD Features=0x20100800 > > [1.000000] AMD Features2=0x1 > > [1.000000] TSC: P-state invariant, performance statistics > > > > cheers. > > alex > > > > > > > > roman