Skip site navigation (1)Skip section navigation (2)
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>