Criticism of garbage collection support in LLVM

This may be of interest:

http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html

People implementing a new Haskell compiler explain why LLVM is an
unsuitable target for them.

It's nice that he claims it's way too high overhead without any, you know, data.

Then again, he also thinks writing a good native code generator isn't
that difficult, so ....

I find the article, and particularly the preceding one (http://lhc-compiler.blogspot.com/2009/01/what-is-lhc.html) to be quite amusing. First, this article should be titled "the case against C / LLVM 2.5", not against LLVM in general. There is nothing in the design that prevents holding GC roots in registers, it is just that noone has implemented support for it yet. It would actually be a pretty simple hack to move the current GC implementation to use the address space support, and say that all pointers into address space 42 are GC'd pointers (for example). This would work fine for languages like haskell and java where the GC doesn't need static metadata associated with the pointers.

I assert that the time and cost to implement an entirely new x86 backend (to start with?) is far more than would be required to add this feature to LLVM (also note that their non-existent code generator doesn't support this feature either). Further, the skill set required to implement a very performant low-level code generator is very different than that required to produce a performant implementation of a high level language like Haskell.

In the end, I consider this to be a yet-another chapter in the "functional language people don't like LLVM" saga. Whether it be small improvements in LLVM tail calls or the fact that LLVM currently pins GC roots to the stack, there is always a "good reason" to justify writing something new, rather than learning and extend an existing system. I'm sure that LLVM being written in C++ (as opposed to, say, ocaml) is part of this as well.

In the end, I think that diversity is good in the compiler world, and wish them the best. It's just not the approach I would take in 2009. :wink:

-Chris

The OCaml Journal has published around 40 articles now. The most popular and
third most popular articles are both about LLVM. So I don't think it is
correct to say that "functional language people don't like LLVM". Indeed, I
thought I was a kook for trying to write a compiler for a functional language
using LLVM until I mentioned it to the OCaml community and half a dozen
people stepped forward with their own alternatives. :slight_smile:

I just want to say that the "functional language people don't like
LLVM" saga is not complete.
I think the LLVM is very cool, and although I've not looked into
supporting GC yet, I'm sure it's possible.
I'd rather try that than duplicating the LLVM effort (I've written
enough code generators).

  -- Lennart

FWIW, I am a physicist with no formal training in compiler writing yet LLVM
has allowed me to create a compiler for a statically-typed functional
language in only one week that outperforms OCaml on a variety of numerical
benchmarks, often by a substantial margin on x86.

Moreover, I took the simplest design choice at every stage in order to
maximize the chances of actually ending up with a working compiler. In
particular, I used a shadow stack based on the pessimistic assumption that
LLVM is uncooperative and I found the performance degradation to be
insignificant on all code except integer Fibonacci which is ~30% slower but
only because I have not yet optimized away the shadow stack for functions
that do not use reference types.

So if anyone is considering writing a compiler for a functional language, I
strongly recommend building upon LLVM.

Chris Lattner wrote:

In the end, I consider this to be a yet-another chapter in the
"functional language people don't like LLVM" saga.

Yet another counterexample:

http://pure-lang.googlecode.com/

LLVM from the ground up, proper tail calls, interactive interpreter,
JIT, easy C interface. Works great. :slight_smile: Without LLVM, I could have never
pulled that off in a couple of months.

Albert

Chris Lattner wrote:

In the end, I consider this to be a yet-another chapter in the
"functional language people don't like LLVM" saga.

Yet another counterexample:

http://pure-lang.googlecode.com/

Hey, this is incredibly cool. I had never heard of pure, nice work! Would you mind writing a blurb for this page?
http://llvm.org/ProjectsWithLLVM/

LLVM from the ground up, proper tail calls, interactive interpreter,
JIT, easy C interface. Works great. :slight_smile: Without LLVM, I could have never
pulled that off in a couple of months.

That's very nice. Do you (or anyone else out there that I don't know about :slight_smile: want to be mentioned in the LLVM 2.5 release notes? I am happy to have the LLVM 2.5 release notes and announcement mention and link to (active and well maintained) projects like this!

Incidentally, my comment about functional language people hating LLVM wasn't meant as a universal statement. I'm thrilled that there are people using and liking it, please help spread the good word! :slight_smile:

-Chris

Hi!

Essential Haskell Compiler (EHC) also has llvm backend.

http://www.cs.uu.nl/wiki/bin/view/Ehc/WebHome
http://www.cs.uu.nl/wiki/bin/view/Stc/CompilingHaskellToLLVM

Cheers,
Csaba

Interesting that John van Schie's slides show a similar result to my own: LLVM
generates faster code than heavily-optimizing existing compilers on all but
one benchmark.

Chris Lattner wrote:

Hey, this is incredibly cool. I had never heard of pure, nice work!

Thanks. I only just started to write about it as we're getting close to
version 1.0 now, so you might hear more about it in the future. :wink:

Would you mind writing a blurb for this page?
http://llvm.org/ProjectsWithLLVM/

Here goes:

Pure (http://pure-lang.googlecode.com/) is an algebraic/functional
programming language based on term rewriting. Programs are collections
of equations which are used to evaluate expressions in a symbolic
fashion. Pure offers dynamic typing, eager and lazy evaluation, lexical
closures, a hygienic macro system (also based on term rewriting),
built-in list and matrix support (including list and matrix
comprehensions) and an easy-to-use C interface. The interpreter uses
LLVM as a backend to JIT-compile Pure programs to fast native code.

In addition to the usual algebraic data structures, Pure also has
MATLAB-style matrices in order to support numeric computations and
signal processing in an efficient way. Pure is mainly aimed at
mathematical applications right now, but it has been designed as a
general purpose language. The dynamic interpreter environment and the C
interface make it possible to use it as a kind of functional scripting
language for many application areas.

(Please feel free to edit for editorial purposes.)

That's very nice. Do you (or anyone else out there that I don't know
about :slight_smile: want to be mentioned in the LLVM 2.5 release notes?

Sure, that would be nice!

Incidentally, my comment about functional language people hating LLVM
wasn't meant as a universal statement. I'm thrilled that there are
people using and liking it, please help spread the good word! :slight_smile:

Will do. But I think that if there are any compiler writers who haven't
heard about LLVM yet then they must have been hiding under a rock. :slight_smile:

Cheers,
Albert

* Daniel Berlin:

It's nice that he claims it's way too high overhead without any, you
know, data.

I was quite suprised by the performance of the conservative
Boehm-Demers-Weiser collector, even in cases where I thought it was
sub-par. So benchmarking available solutions makes sense indeed. :sunglasses:

(Lack of continuations is probably a better excuse if you don't want
to use LLVM, especially if you don't want to perform whole-program
analysis.)

And the followup:

http://lhc-compiler.blogspot.com/2009/01/why-llvm-probably-wont-replace-c.html

Keir Mierle wrote:

And the followup:

http://lhc-compiler.blogspot.com/2009/01/why-llvm-probably-wont-replace-c.html

And if you're pointing to that, you should probably also read the next followup:

http://lhc-compiler.blogspot.com/2009/01/llvm-is-great.html

Nick