llvm dev - Jan 2009 - [LLVMdev] 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 ....

On Sat, Jan 17, 2009 at 1:18 PM, Mikhail Glushenkov <foldr at
codedgers.com> wrote:
> 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.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

On Jan 17, 2009, at 10:18 AM, Mikhail Glushenkov wrote:
> 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.
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. ;-)

-Chris

On Saturday 17 January 2009 19:02:47 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.
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. :-)

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

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

On Sat, Jan 17, 2009 at 7:02 PM, Chris Lattner <clattner at apple.com>
wrote:
>
> On Jan 17, 2009, at 10:18 AM, Mikhail Glushenkov wrote:
>
>> 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.
>
> 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. ;-)
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

On Saturday 17 January 2009 18:18:50 Mikhail Glushenkov
wrote:
> 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.
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.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

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. :) Without LLVM, I could have never
pulled that off in a couple of months.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag

* 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. 8-)

(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

On Sat, Jan 17, 2009 at 1:18 PM, Mikhail Glushenkov <foldr at
codedgers.com> wrote:
>
> 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.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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
> On Sat, Jan 17, 2009 at 1:18 PM, Mikhail Glushenkov <foldr at
codedgers.com> wrote:
>> 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.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>