[lkml]   [2009]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[rfc] built-in native compiler for Linux?

    * Steven Rostedt <> 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)

    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.


     \ /
      Last update: 2009-04-22 11:05    [W:0.038 / U:22.956 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site