From owner-freebsd-stable@FreeBSD.ORG Fri May 11 08:23:03 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DC42106566B; Fri, 11 May 2012 08:23:03 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 04EFB8FC0A; Fri, 11 May 2012 08:23:01 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA14374; Fri, 11 May 2012 11:22:59 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SSl7q-0004CL-TP; Fri, 11 May 2012 11:22:58 +0300 Message-ID: <4FACCC61.6030000@FreeBSD.org> Date: Fri, 11 May 2012 11:22:57 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <4FAA3912.3030801@dssgmbh.de> <4FAA4A11.808@FreeBSD.org> <4FAA5E70.7030508@dssgmbh.de> <4FACB396.6060800@FreeBSD.org> <20120511080906.GL2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120511080906.GL2358@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, John Baldwin , Alfred Bartsch Subject: Re: i386 -march=xxx behavior X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 08:23:03 -0000 on 11/05/2012 11:09 Konstantin Belousov said the following: > On Fri, May 11, 2012 at 09:37:10AM +0300, Andriy Gapon wrote: >> on 09/05/2012 15:09 Alfred Bartsch said the following: >>> Am 09.05.2012 12:42, schrieb Andriy Gapon: >>>> on 09/05/2012 12:29 Alfred Bartsch said the following: >>>>> This behavior is restricted to 32-bit servers (i386), all 64-bit >>>>> servers (amd64) work without any problem, as expected. >>>>> >>>>> After some analyzing, it seems to me that the actual size of >>>>> gptboot does matter (16723 bytes, >16kB). In amd64 environment >>>>> (same source version) the actual size of /boot/gptboot is only >>>>> 15443 bytes. >>> >>>> Weird. Both amd64 and i386 builds should produce the same binaries >>>> as the boot code is built with -m32 -march=i386 on amd64. But I can >>>> reproduce this, so it seems that the compilation is indeed done >>>> differently. >>> >>>> Heh, it seems that it is -march=i386 flag that makes all the >>>> difference. Maybe we should use this flag even when doing native i386 >>>> builds... >>> >>> >>> after adding "-march=i386" to CFLAGS in Makefile everything looks ok >>> (filesize: 15443, as you predicted), so I would opt for using this flag >>> in the future. >> >> Here is a small investigation into the -march flag. Not sure if it is of >> any practical significance, I just was curious. >> >> First, seems that neither of i386/i486/i586/i686 values for this flag >> nor absence of it implies features like MMX, SSE, and so on. (Saying >> this because of some assumptions about i686) >> >> For the base GCC specifying -march with the above values is equivalent >> to specifying -mtune with the same values, when mtune is not explicitly >> set. Using "i686" or omitting the flag is equivalent to -mtune=generic. >> >> Note that this happens despite a FreeBSD-specific change to (base) GCC >> that makes i486 a default arch. Derivation of the tune value from the >> arch value, if any, or defaulting it otherwise is done earlier than >> defaulting of the arch value. Specifically I am talking about the block >> that deals with ix86_tune_string that precedes the block for >> ix86_arch_string. >> >> So it seems that at the moment our sys/boot code is effectively compiled >> with -mtune=generic for i386 target (amd64 target has an explicit >> -march=i386 - I wonder why not i486). >> >> I think that in terms of instructions repertoire the difference is only >> in availability of cmpxchg, cmpxchg8b, and xadd instructions (ignoring >> the "system" instructions that should not be generated by a compiler from >> C code). And I guess that the sys/boot code is simple enough to not >> require these instructions? Otherwise, mtune seems to affect layout of >> the generated code and preference for some instructions over others. >> >> Again, not sure what conclusions can be made... > > -march=i686 also turns on use of cmov*. So, this is the important thing that I missed. Then, it seems our default gcc behavior is -march=i486 -mtune=generic after all. -- Andriy Gapon