Date: Wed, 13 Sep 2006 17:25:35 -0700
From: Chuck Swiger <cswiger@mac.com>
To: Gary Kline <kline@sage.thought.org>
Cc: freebsd-stable <freebsd-stable@freebsd.org>
Subject: Re: optimization levels for 6-STABLE build{kernel,world}
Message-ID: <0B8BF03E-8F4A-4279-850B-2EA7FF5E1B89@mac.com>
In-Reply-To: <20060913234934.GA92067@thought.org>
References: <200609130905.k8D95idk062789@lurza.secnetix.de> <4507CC9B.60704@sun-fish.com> <20060913234934.GA92067@thought.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0B8BF03E-8F4A-4279-850B-2EA7FF5E1B89>