You could just enable -O2 and the following: -frename-registers and -fweb. -O3 is simply -O2 plus those 3 options.

On Wed, 21 Jul 2004 20:50:01 -0400
Adam Petaccia <adam@...> wrote:

> With gcc, is there a way to enable all -O3 options but function 
> inlines?  Would -fno-inline work or something like that?
> 
> Mario Domenech Goulart wrote:
> 
> >Hello,
> >
> >There's an interesting discussion in the OpenBSD mailing
> >list about the use of inline.
> >
> >Here's the beginning of the thread about this topic:
> >
> >,----[ http://www.sigmasoft.com/cgi-bin/wilma_hiliter/openbsd-tech/200407/msg00175.html ]
> >| inline considered harmful.
> >| 
> >|     * To: tech@...
> >|     * Subject: inline considered harmful.
> >|     * From: Artur Grabowski <art@...>
> >|     * Date: 21 Jul 2004 03:54:46 +0200
> >|     * User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
> >| 
> >| Today we did a bunch of removal of inline functions in the kernel.
> >| It all started to make floppies fit, but now it's a quest.
> >| 
> >| If you think that I'm crazy doing this because it might hurt your
> >| precious performance, go back to your vax and leave the performance
> >| tuning to people who have a cache.
> >| 
> >| Every single inline we removed today (and there are more in the
> >| pipeline and even more waiting to be fixed) shrunk the code and MADE
> >| IT FASTER.  Yes, modern cpus have something called "cache". The cache
> >| prefers the code to be smaller, rather than free from function calls.
> >| Yes, some cpus have expensive function call overhead. Don't use them.
> >| i386 has quite expensive function calls, on the other hand it doesn't
> >| have any relevant amount of registers either. So a function call
> >| instead of the same function inlined can potentially make the job
> >| easier for the register allocator in the compiler which could eat the
> >| overhead. At the same time the instruction cache can run the same code
> >| in the same place, instead of loading it from main memory 4711 times.
> >| And guess what? The stack on i386 is in the cache too, so the function
> >| call overhead isn't that bad anyway.
> >| 
> >| I'm tired of seeing code where everything is made inline just because
> >| someone acted on a meme that hasn't been true for over a decade. Bloat,
> >| bloat and more bloat. Since people can't use inline correctly (it does
> >| have valid and correct uses), from now on inline in the OpenBSD kernel
> >| is considered to be a bug until proven otherwise. So. Next time I see
> >| code that adds to the bloat with inlines, I expect performance figures
> >| and kernel size comparisons that show that the inline actually
> >| contributes anything. Otherwise the code does not go in.
> >| 
> >| There's still a lot of work to be done in the kernel (yes, macros can
> >| be evil too, just see nfs), so send diffs. And there's a whole
> >| unexplored field in userland too.
> >| 
> >| //art
> >`----
> >
> >Mario
> >
> >
> >--
> >gentoo-performance@g.o mailing list
> >
> >
> >  
> >
> 
> --
> gentoo-performance@g.o mailing list
>