-O3 Compiler Optimization Level Still Deemed Too Unsafe For The Linux Kernel

[ms178]

I've been using -march=native for a very long time, O3 for a number of years, and now also Clang & LTO without issue

That, and I even throw Polly into the mix.

On the other hand, I've seen some breakage with certain modules, configs, Full LTO and so forth from time to time. But all could be worked around for my purposes so far.

[FireBurn]

I've been using -march=native for a very long time, O3 for a number of years, and now also Clang & LTO without issue

[sdack]

Kind of surprised to learn that it's even supported at all to compile different kernel modules with different compiler flags. I wonder what the reason is for supporting that?

To have it as an option for where it is needed. It makes sense to have compression and encryption functions optimised. A driver and even an entire subsystem, which implements complex algorithms as part of their operation, can sometimes benefit from more aggressive optimisations.

What is trying to be avoided by not using -O3 everywhere is to optimise critical code beyond reason and thereby to introduce undefined and possibly even false behaviour. Some parts of the kernel have to work flawlessly to avoid lockups, hangs, security holes or it could even damage the hardware.

Although the kernel allows modules to have their own flags can one also influence the compiler's behaviour with #pragma's from within the source files, too.

[linner]

In all the years I have been writing high-performance code I've not noticed much difference with -O3 anyway. A tiny bit, but nothing worth getting bothered over.

[CommunityMember]

LLVM? Even -O3 in its worst days is a lot better and more trustworthy then building the kernel with this unreliable untrustable mess.

What is the technical argument for your claims that LLVM is unreliable and/or untrustable?

[CommunityMember]

Kind of surprised to learn that it's even supported at all to compile different kernel modules with different compiler flags. I wonder what the reason is for supporting that?

There will always be certain code constructs for which -O3 makes a significant difference in performance critical code, and for which validation of the results is possible. (De)Compression is the poster child.

[HD7950]

On Archlinux i compile manually some of my most used packages using -O3 and march=native flags, kernel is one of them, and never had a problem.

[zcansi]

Kind of surprised to learn that it's even supported at all to compile different kernel modules with different compiler flags. I wonder what the reason is for supporting that?

[indepe]

Doesn't RedHat backport fixes to such known bugs to previous compiler versions? Or maybe does -O3 need to be split into -O3 and -Oe (e for experimental) ?

I'd think this would be a priority.

[Vistaus]

This Torvalds quote is funny -


And up until a few weeks ago, Linus was literally accepting any garbage patches from University of Minnesota delinquents for no reason whatsoever and without subjecting them to even the most cursory review.

So, who cares about being "careful" more, I wonder?

IIRC, it wasn't Linus who accepted the patches - it was Greg.