> I think it was Ingo that let out the idea, and I'm starting to> like it.>> Perhaps we should fork off gcc and ship Linux with its own> compiler. This way we can optimize it for the kernel and not worry> about any userland optimizations.

I didnt suggest forking GCC. A kernel-special GCC would likely justbecome an inferior fork of GCC over time and would fizzle out.There's 100 times more user-space code than kernel-space code andGCC is too large and too legacy-laden to really be appropriate forthat purpose.

What i think makes sense is to build a _new_ precompiler / compiler/ assembler / linker combo for Linux, from scratch, hosted in thekernel proper.

In the past 15 years of Linux we've invested a lot of time andeffort into working around and dealing with compiler crap. We wasteda lot of opportunities waiting years for sane compiler features toshow up. We might as well have invested that effort into buildingour own compiler and could stop bothering about externalities. TheLinux kernel project certainly involves the right kind of people whocould make something like this happen.

A good technical basis for that would be Sparse, and it could startby acting as a drop-in replacement for CPP and it could feed itsoutput to GCC with little changes. Sparse is small, has a very tidycode base and is already useful today as an extended static sourcecode checker.

The Sparse codebase could move into the kernel proper, underlinux/sparse/ or so - so the preprocessor/compiler and the kernelcould be in precise feature and bugfix lock-step with no artificialexternal synchronization.

We have a lot of annoying preprocessor limitations that Sparse couldhelp with straight away. We'd also get Sparse type checking bydefault. So it's helpful even without any code generator support.

Then, if this model works out, we could experiment with adding acode generator backend to Sparse. I think Jeff Garzik experimentedwith that in the past with some surprisingly quick (but incomplete)results.

Since most of the performance-critical code in Linux ishand-optimized already, we dont even need all that many complex,exotic optimizations - we want to encourage common-sense codingpractices. Furthermore, a lot of optimizations in GCC are driven bySPECint and SPECfp benchmarketing, with little practical relevanceto 99% of the apps, including the kernel.

There would always be an 'output to GCC' kind of compatible buildchannel as well, for CPU architectures that dont have native codegenerator support yet. We'd also do that to generally keep ouroptions open, in case we are wrong about it all or in case some evenbetter compiler project pops up.