From owner-freebsd-current@FreeBSD.ORG Mon Sep 12 08:40:27 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C9EB106566C; Mon, 12 Sep 2011 08:40:27 +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 B4F088FC12; Mon, 12 Sep 2011 08:40:26 +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 LAA05009; Mon, 12 Sep 2011 11:40:24 +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 1R3240-000KoS-Fg; Mon, 12 Sep 2011 11:40:24 +0300 Message-ID: <4E6DC577.9050007@FreeBSD.org> Date: Mon, 12 Sep 2011 11:40:23 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110907 Thunderbird/6.0.2 MIME-Version: 1.0 To: FreeBSD-Current , freebsd-fs@FreeBSD.org References: <4E6DB696.1080608@FreeBSD.org> In-Reply-To: <4E6DB696.1080608@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: archaic/useless CFLAGS options for x86 boot blocks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 08:40:27 -0000 on 12/09/2011 10:36 Andriy Gapon said the following: > > This email is in part inspired by the following problem: > http://article.gmane.org/gmane.os.freebsd.current/135292 > So "harmful" could also be added to the subject line. > > So here is my proposal. I would like to clarify that my intention was to solicit opinions, explanations, discussions, alternative proposals and *testing*. > Part I. ZFS and GPT bootblocks. > > I believe that we do not need here any extra optimizations and happy dances that > seem to be carried over from boot2. > I think that just the -Os should be sufficient of optimization flags. Maybe > even that is not really required. > Rationale: > - these boot blocks are not as nearly space-constrained as boot2 > - using untypical flags increases chances of hitting compiler bugs, > especially for those compilers where we are stuck with > unsupported / locally-maintained versions or where a compiler is maturing yet > - assembly / machine code and debugging may become easier > > Additionally, the '/align/d' '/nop/d' filtering of the intermediate assembly > file seems to be not needed for zfsboot. > > Part II. The original boot2. > > My testing shows that -Os -fomit-frame-pointer are sufficient to produce a small > enough boot2 image (~300 bytes remain available with gcc, 51 bytes for clang). > -mrtd -mregparm=3 do not change size with gcc, but with clang they increase > _available_ space to 79 bytes. > > The '/align/d' '/nop/d' filtering seems to shave off only 7 bytes here. > Not suggesting anything, just an observation... > > Part III. History. > > It seems that all those optimization related options were introduced very long > time ago when the compiler(s) were quite different from what they are now. > So, some re-evaluation may be (long over)due. > For example, -fno-unit-at-a-time is definitely an anti-optmization option and it > was introduced to fight some gcc bugs way back in 2004 (r132870). Its merits > have never been re-evaluated after switch to gcc 4.2, it seems. > -fno-guess-branch-probability and -mno-align-long-strings are even less obvious > options (see e.g. r108149). > > > Finally, here is a diff: > http://people.freebsd.org/~avg/boot-cflags.diff > All the boot blocks are boot tested in qemu. > boot2 is also tested with -mrtd -mregparm removed. > -- Andriy Gapon