Message-ID: <20090422085828.GA16917@elte.hu>
Date:	Wed, 22 Apr 2009 10:58:28 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Rostedt <rostedt@...dmis.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Jeff Garzik <jgarzik@...ox.com>,
	Alexander Viro <viro@....linux.org.uk>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tejun Heo <tj@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Sam Ravnborg <sam@...nborg.org>,
	Jonathan Corbet <corbet@....net>,
	"H. Peter Anvin" <hpa@...or.com>, Greg KH <gregkh@...e.de>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Theodore Tso <tytso@....edu>,
	Arjan van de Ven <arjan@...radead.org>,
	Christoph Hellwig <hch@....de>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Zhaolei <zhaolei@...fujitsu.com>, Li Zefan <lizf@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	"Frank Ch. Eigler" <fche@...stic.org>,
	Tom Zanussi <tzanussi@...il.com>,
	Jiaying Zhang <jiayingz@...gle.com>,
	Michael Rubin <mrubin@...gle.com>,
	Martin Bligh <mbligh@...gle.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Neil Horman <nhorman@...driver.com>,
	Andi Kleen <andi@...stfloor.org>,
	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>,
	Pekka Enberg <penberg@...helsinki.fi>
Subject: [rfc] built-in native compiler for Linux?


* Steven Rostedt <rostedt@...dmis.org> wrote:

> 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 just 
become an inferior fork of GCC over time and would fizzle out. 
There's 100 times more user-space code than kernel-space code and 
GCC is too large and too legacy-laden to really be appropriate for 
that purpose.

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

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

A good technical basis for that would be Sparse, and it could start 
by acting as a drop-in replacement for CPP and it could feed its 
output to GCC with little changes. Sparse is small, has a very tidy 
code base and is already useful today as an extended static source 
code checker.

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

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

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

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

There would always be an 'output to GCC' kind of compatible build 
channel as well, for CPU architectures that dont have native code 
generator support yet. We'd also do that to generally keep our 
options open, in case we are wrong about it all or in case some even 
better compiler project pops up.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists