Re: Pass 4 (non-)optimization speedup

[Mark Wielaard <mjw at redhat dot com>]

On Sun, 2009-07-12 at 16:25 +0200, Mark Wielaard wrote:
> On Sat, 2009-07-11 at 21:51 -0400, Frank Ch. Eigler wrote:
> >   Frankly, I'm surprised it
> > even compiles, since some kernel code is unbuildable without
> > optimization.
> 
> And that surprises me. Obviously I tried it out on some different
> kernels/architectures (i386/x86_64/fedora/2.6.29/rhel/2.6.18) before
> implementing it. And afterwards of course I ran make installcheck to
> make sure there were no regressions (there weren't, it just was minutes
> faster!). If you have any examples of things that won't compile with the
> new default please do let me know (and preferably add them to the
> testsuite). 

We discussed this a bit on IRC. The issue is that some code that we
compile together with a module might depend on source of the kernel that
depends on being optimized in a particular way. For example locking
code. Other code might only produce warnings when optimized (unitialized
variables for example) and so confuse a user suddenly something doesn't
compile (because of -Werror) on higher opt-levels than the default. Will
actually found some ia64 code that relies on optimization of code so
that gcc doesn't emit resolvable symbols (in a complicated if-then-else
switch statement).

So, I made the default the kernel opt-level one again (which is -O2 or
-Os depending on CONFIG_CC_OPTIMIZE_FOR_SIZE).

This is really a shame, gcc is really a lot slower compiling with -O2.
It would be good to find some other way to make pass 4 quicker by
default.

Cheers,

Mark