Intro to the LLVM MC Project | Hacker News Reader

Intro to the LLVM MC Project

blog.llvm.org

56 pointsmattyb5 comments

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.

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.

Support for interesting stack models...seems to extend little more than tail call support

I'm curious how would it extend further?

Yes, that's a risk (biting off more than they can chew), but the LLVM folks have proven that they're in it for the long haul, even with just their previously ambitious goals.

Since this is a subproject they're not depending on (yet), it seems like a safe bet.

And, if it pans out, their whole infrastructure takes a incremental leap.

They seem to be winning by incremental leap after leap, so more power to them.

The risk of untaken paths atrophying is always real, but, since this is OSS, it's going to be the usual "anyone who cares can scratch his own itch."

Plus, they do have a lot of diverse (academic and commercial) projects depending on them, pushing them in various directions, so it's not likely that they'll become laser-focused on Mac/Linux.

(Enough armchair quarterbacking. ;-)

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

Reply on news.ycombinator.com