Using LLVM for build package instead gcc, why not?

[Horst H. von Brand]

Jonathan MERCIER <bioinfornatics at gmail.com> wrote:
> LLVM itself could allow for much greater flexibility in programming
> language choice. It can allow for anyone to take any language and output
> it in bytecode, machine code, javavm code and so on.

Sorry, but many interpreted languages (like Python, Perl, even emacs LISP)
have their own bytecode (for good reasons, most of the time) and their own
compilers to said bytecode. JVM is a _terrible_ architecture (somebody
quipped it was carefully designed to be impossible to implement
efficiently), other bytecodes are even more tailored for their respective
languages. So this isn't _that_ great an idea.

>                                                      If we can rip out
> the multitude of compilers on different architectures and replace it
> with one compiler base that does many different languages people might
> start picking languages based on their merits rather than support (since
> it just needs LLVM support to be supported).

This idea was behind a dream of an universal intermediate language (UIL or
some such). The problem is that designing such an UIL is extremely hard to
do (and wasn't done because of that): You have to encode enough of the
source code to be useful for the back end, and hide enough of the target to
make the frontend truly target-independent; all the while not leaving too
much hard work for the backend. Consider the variety of source languages
you want to use: Perl (dynamic, heavily text based), C (static, "high level
assembly language"), C++ (machine-near object oriented), Java (with
guarantees that nothing can go too far off), functional languages like
Haskell or Scheme, stuff like Erlang, ...

> If we could swap out old C compilers for a more generic LLVM compiler
> for core components like the kernel,

Won't happen until clang generates much better code than GCC; in the
meanwhile it'll have to grok all GCC extensions.

>                                      userspace libs

Ditto (mostly)

>                                                     and so on. In the
> future people might just make the decision to move to D since the
> architecture is all there and all their old code works but they get all
> the new features.

Would need compatilility shims to extant C libraries. Plus people won't
just rewrite years of work if it isn't for _massive_ advantages (twice as
fast or one tenth of the bugs for little work).

>                   Think of Linux distros being built entirely on LLVM.
> There are also the other advantages such as dumping in JIT compilers and
> automatic threading in LLVM to take advantage of the many processors
> systems are starting to get.

Automatic paralelization is still a just a glint in researcher's eyes, some
50 years later...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  +56 32 2797513