From owner-freebsd-stable@FreeBSD.ORG Thu Sep 14 04:42:48 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 7279816A4E0 for ; Thu, 14 Sep 2006 04:42:48 +0000 (UTC) (envelope-from kline@sage.thought.org) Received: from sage.thought.org (dsl231-043-140.sea1.dsl.speakeasy.net [216.231.43.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE78543D68 for ; Thu, 14 Sep 2006 04:42:43 +0000 (GMT) (envelope-from kline@sage.thought.org) Received: from sage.thought.org (kline@localhost [127.0.0.1]) by sage.thought.org (8.13.6/8.12.10) with ESMTP id k8E4ggB9094003; Wed, 13 Sep 2006 21:42:43 -0700 (PDT) (envelope-from kline@sage.thought.org) Received: (from kline@localhost) by sage.thought.org (8.13.6/8.13.1/Submit) id k8E4ggLT093998; Wed, 13 Sep 2006 21:42:42 -0700 (PDT) (envelope-from kline) Date: Wed, 13 Sep 2006 21:42:41 -0700 From: Gary Kline To: Chuck Swiger Message-ID: <20060914044241.GA92358@thought.org> References: <200609130905.k8D95idk062789@lurza.secnetix.de> <4507CC9B.60704@sun-fish.com> <20060913234934.GA92067@thought.org> <0B8BF03E-8F4A-4279-850B-2EA7FF5E1B89@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0B8BF03E-8F4A-4279-850B-2EA7FF5E1B89@mac.com> X-Organization: Thought Unlimited. Public service Unix since 1986. X-Of_Interest: Observing twenty years of service to the Unix community User-Agent: Mutt/1.5.11 Cc: Gary Kline , 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 04:42:48 -0000 On Wed, Sep 13, 2006 at 05:25:35PM -0700, Chuck Swiger wrote: > 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. Isn't the compiler intelligent enough to have a reasonable limit, N, of the loops it will unroll to ensure a faster runtime? Something much less than 1000, say; possibly less than 100. At least, if the initializiation and end-loop code *plus* the loop code itself were too large for the cache, my thought is that gcc would back out. Imay be giving RMS too much credit; but if memory serves, thed compiler was GNU's first project. And Stallman was into GOFAI, &c, for better/worse.[1] Anyway, for now I'll comment out the unroll-loops arg. > > 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). Well, I'd added the no-strict-aliasing flag to make.conf! Pointers give me indigestion ... even after all these years. Thanks for your insights. And the URL. gary [1]. Seems to me that "good old-fashioned AI" techniques would work in something like a compiler where you probblyhave a good idea of most heuristics. -gk > > -- > -Chuck > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Gary Kline kline@thought.org www.thought.org Public service Unix