First of all it often produces slower code than -O2 or -Os. Sometimes it produces longer code due to loop unrolling which may be in fact slower due to worse cache performance of code.

As it was said it sometimes produces wrong code. It may be either due to error in optimalization or error in code (like ignoring strict aliasing). As kernel code sometimes is and sometimes have to be 'smart' I'd say it is possible that some kernel developer made some error. I experienced various strange problems, like crashing of userspace utilities, when I compiled kernel with gcc 4.5 which at that point was stable. I still use gcc 4.4 for kernel and several selected userspace utilities due to various bugs. The same may apply for -O3.

I don't think it offers much benefit for the Linux kernel. The kernel does not do heavy computations and in places it does, it is optimized with assembly. -O3 flag will not change the cost of context switching or speed of I/O. I don't think something like <0.1% speedup of overall performance is worth it.

Linux is compiled with -fno-strict-aliasing since Linus thinks gcc is being stupid and overly restrictive since it does stupid things like treat values as different even though they blatantly obviously are not (ie the aliasing was introduced inside one function and the compiler can see it). see mail-archive.com/linux-btrfs@vger.kernel.org/msg01647.html
–
Spudd86Oct 31 '10 at 16:56

@Spudd86: Did he mean that they are obviously not for human being reading code or for compiler? As I said - Kernel sometimes need to do smart things that userspace programs should not do. What makes sense for userspace (heavy optimization in some areas) may make no sense for kernel (larger amount of smart code + bottleneck in different places).
–
Maciej PiechotkaOct 31 '10 at 17:14

@Spudd86: I disagree with it then. Making compiler 'smart enough' to spot such 'obvious' things is not trivial. So the only possible way is a) produce only slow(er) code (which is unacceptable for some use cases in, say, HPC) and/or force programmers to manually optimize the code b) make the rules stricter to allow 'dumber' compiler to make optimalization - route taken by C standard.
–
Maciej PiechotkaJul 24 '13 at 22:07

Note that large chunks of the toolchain (glibc in particular) flat out don't compile if you change optimization levels. The build system is setup to ignore your -O preferences for these sections on most sane distros.

Simply put, certain fundamental library and OS features depend on the code actually doing what it says, not what would be faster in many cases. -fgcse-after-reload in particular (enabled by -O3) can cause odd issues.

-O3 uses some aggressive optimisations that are only safe if certain assumptions about register use, how stack frames are interacted with, and function reentrancy are true, and these assumptions are not guaranteed to be true in some code like the kernel especially when inline assembly is used (as it is in some very low level parts of the kernel and its driver modules).

Over the last 10 years I've been running multiple Gentoo systems with 1000+ packages using -O3 -march=native globally and have yet to run into any of these mythical stability issues that -O3 is supposed to have. Benchmarks of CPU intensive applications (like math/science apps) consistently show -O3 to produce faster code, after all it would be pointless if it didn't. For a majority of desktop apps CFLAGS don't matter much as much anyway since they are IO bound, but it matters a lot for server side stuff that is CPU bound.

While you can get away with using -O3 and other optimizations knobs on most applications (and it can result in speed improvements), I would hesitate to use such tweaks the kernel itself or on the tool chain required for building it (compiler, binutils, etc.).

Think about it: Is a 5% performance gain of the raid and ext3 subsystems worth system crashes or potential data loss and/or corruption?

Tweak all the knobs to want for that Quake port you're playing or the audio/video codecs you use for ripping your DVD collection to divx files. You'll likely see an improvement. Just don't mess w/ the kernel unless you have time to waste and data you can bear to lose.

I'am not asking if it is worth or not, safe or not, or why we shouldn't do this, what I'am asking is the fact, does it really produce bugs in real application?, does it ever occurred?, does it proved so..
–
uraySep 5 '10 at 1:16