From owner-freebsd-stable@FreeBSD.ORG Thu Sep 14 00:25:41 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBE3816A40F for ; Thu, 14 Sep 2006 00:25:41 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76C7543D6A for ; Thu, 14 Sep 2006 00:25:38 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/8.12.11/smtpout16/MantshX 4.0) with ESMTP id k8E0PcH7006020; Wed, 13 Sep 2006 17:25:38 -0700 (PDT) Received: from [17.214.13.96] (a17-214-13-96.apple.com [17.214.13.96]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id k8E0PahO023606; Wed, 13 Sep 2006 17:25:37 -0700 (PDT) In-Reply-To: <20060913234934.GA92067@thought.org> References: <200609130905.k8D95idk062789@lurza.secnetix.de> <4507CC9B.60704@sun-fish.com> <20060913234934.GA92067@thought.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B8BF03E-8F4A-4279-850B-2EA7FF5E1B89@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Wed, 13 Sep 2006 17:25:35 -0700 To: Gary Kline X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAQAAA+k= X-Language-Identified: TRUE Cc: freebsd-stable Subject: Re: optimization levels for 6-STABLE build{kernel,world} 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: Thu, 14 Sep 2006 00:25:41 -0000 On Sep 13, 2006, at 4:49 PM, Gary Kline wrote: > A couple of things. Will having gcc unroll loops have any > negative consequences? Yes, it certainly can have negative consequences. The primary intent of using that option is to change a loop from executing the test or control block for each iteration that the body is executed, to executing the loop body several times and checking the test or control block less often. The issue is that there is often additional setup or post-loop fixups to ensure that the loop body actually is executed the right number of times, which makes the generated binary code much larger. This can mean that the loop no longer fits within the L1 instruction cache, which will usually result in the program going slower, rather than faster. Using the option will always increase the size of compiled executables. > (I can't imagine how:: but better > informed than to have something crash inexplicability.) > With 6.X safe at -O2 and with -funroll-loops, that should be > a slight gain, right? -funroll-loops is as likely to decrease performance for a particular program as it is to help. One particular caveat with using that option is that the increase in program size apparently causes the initial bootloader code to no longer fit within a single sector, making the system unbootable. > [Dumb] questions:: first, what does the compiler do with > "-fno-strict-aliasing"? It prevents the compiler from generating buggy output from source code which uses type-punning. http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html A safe optimizer must assume that an arbitrary assignment via a pointer dereference can change any value in memory, which means that you have to spill and reload any data being cached in CPU registers around the use of the pointer, except for const's, variables declared as "register", and possibly function arguments being passed via registers and not on the stack (cf "register windows" on the SPARC hardware, or HP/PA's calling conventions). -- -Chuck