
Intro to the LLVM MC Project - mattyb
http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html
======
barrkel
One of my concerns with LLVM is its appetite for "elegance" means it risks
biting off more than it can comfortably chew. A wonderfully general and
composable framework is all well and good, but as a practical matter, there
are more direct routes when what you want is to arrive at a destination.

I work on the Delphi compiler. In Delphi 2 (released in 1996), the compiler,
in 65K lines of C source, implemented not just the usual lexer, parser, OO
type system, optimizer, code generator etc., but also a build system
(conventionally the main .dpr specified all units used by project), an object
file reader and writer, a unit file reader and writer (a richer object file
with full symbol table info), a smart linker and a resource linker. It could
do that in part because it only targeted x86 on Windows, but also because it
had a goal of simplicity of use in mind: all you needed was the compiler
executable and a path to the RTL units, and you could compile anything you
needed without fuss. Not wholly relying on 70s era assembler and linker
technology meant that e.g. bad links with mismatched import and export symbol
types could be eliminated.

LLVM earlier had a goal of being able to skip the assembler step and produce
object files directly. But it appears that since that didn't work out too
well, now LLVM is reimplementing a general assembler framework entirely. The
risk is that they are expanding the project's focus so much that in its
breadth, it gets stretched a little thin so that scenarios not tested by the
mainline path of Clang on Mac / Linux atrophy. As it is, support for precise
GC doesn't seem wonderful, and there's no support for Win32 SEH, etc. Support
for interesting stack models (think e.g. Erlang, stackless python) seems to
extend little more than tail call support.

That said, it's great that LLVM exists, and can act as a hub for commercial
investment in open source back end compiler technology. I'm currently playing
with LLVM as a back end for a toy project right now.

~~~
plesn
LLVM began purely as a research project, unlike many other compilers, so I
think it's a bit harsh to blame its `appetite for "elegance"`.

Free software had GCC, and in my opinion LLVM has the success it has _because_
it is composable. Even with the 4.x branch of GCC with GIMPLE, GCC was not
made so pluggable (due to political reasons if I understand well), so they do
not compete exactly on the same ground, and that's why they both exist.

------
Dellort
LLVM should be ported to C to be future proofed. Anything other than C++ at
the very least.

