From owner-freebsd-current@FreeBSD.ORG Mon Sep 12 07:37:00 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 EB474106564A; Mon, 12 Sep 2011 07:37:00 +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 49E2D8FC14; Mon, 12 Sep 2011 07:36:58 +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 KAA04123; Mon, 12 Sep 2011 10:36:57 +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 1R314a-000Kla-NY; Mon, 12 Sep 2011 10:36:56 +0300 Message-ID: <4E6DB696.1080608@FreeBSD.org> Date: Mon, 12 Sep 2011 10:36:54 +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 X-Enigmail-Version: undefined Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: 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 07:37:01 -0000 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. 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