Did you consider use libJIT? I am interested about your opinion, if you compare both LLVM and libJIT for your work. Because as our experiments show for ECMA-335 Microsoft Common Intermediate Language Infrastructure, Common Intermediate Runtime, and Common Intermediate Language, libJIT is both much faster, platform independent, and remarkably easier to use than LLVM (or GNU Lightning). It was one of the reason we actually started developement of libJIT. The other libraries were not suitable for our needs, when we started libJIT, to implement an advanced Just-In-Time compiler, which would run much faster than Mono Just-In-Time compiler. And as of today which we actually archieved as seen in following results in end of text.

Also LLVM is not suitable for Just-In-Time compilation at all in real projects, because of huge compilation time. Moreover, it does not support a large range of features needed to implement ECMA-335. These are just a couple of them:

* the whole spectrum of ECMA 335 for CLR types and operations

* async exception handling

* precise stack marking

* multiple custom call conventions

* fast Just-In-Time compilation

libJIT from end of 2008 runs 26% faster in PNETMARK than the commercial Mono 2.0 from August 2008, and faster 12.5% than Mono 2.2 from January 2009, and Mono 2.4 from March 2009.

You can try this:

http://code.google.com/p/libjit-linear-scan-register-allocator/

This is my research experimental branch of libJIT.

There is a tutorial with libJIT here:

http://www.gnu.org/software/dotgnu/libjit-doc/libjit.html

I am very, very surprised that you have left a message for me.
Although I was talking about your examples and LLVM and Rubinius,
most of contents were written in Chinese. I didn’t expect there
would be any reader who’s first language wasn’t Chinese.

So, I am very surprised and glad to see your message.
If you were interested in some content of that blog post,
I could translate some of them to English for you,
if you don’t mind my poor, strange English sentence.

*

Let’s get back to your examples. At first, I couldn’t find a way to
compile the examples. After searching header files and llvm-config,
the examples ran fine. I was glad to reach here.

But I thought it’s a bit strange that your “create” function which
creates JIT module, was skipping “function label”, lacking a switch
case to find out which function it should call this time.

By talking about “function label”, I mean the 0, 1, 2 in our source
program. 0 stands for set, 1 stands for add, and 2 stands for show.

Then I started to add the switch case in your create function,
thinking it should let me rewrite our source program to such as:

int program[] = {
0, 0, 5, // res[0] = 5
2, 0, // puts res[0]
1, 0, 0, 4, // res[0] = res[0] + 4
2, 0, // puts res[0]
1, 1, 0, 7, // res[1] = res[0] + 7
2, 1 // puts res[1]
};

Problems occurred here.
Segmentation fault, or strange result, e.g. -2153546.

blah blah blah… time passed.

I started to think perhaps there would be a bug in your examples.
The body bytecode (or bitcode?) emitted by llvm, i.e.,

define void @body(i32* %ops, i32* %registers) {
entry:
call void @set( i32* %ops, i32* %registers )
%tmp3 = getelementptr i32* %ops, i32 3 ; [#uses=1]
call void @add( i32* %tmp3, i32* %registers )
%tmp31 = getelementptr i32* %ops, i32 4 ; [#uses=1]
call void @show( i32* %tmp31, i32* %registers )
ret void
}

I thought it’s very strange that the second getelementptr told
%ops to step 4, just like “ops + 4″ in C. Then it passed %tmp31,
i.e. “ops + 4″ to show. Shouldn’t it be “ops + 3 + 4″ ?

Then I took out the line:

GetElementPtrInst* ptr2 = GetElementPtrInst::Create(ops, const_4, “tmp3″, bb);

and changed it to:

GetElementPtrInst* ptr2 = GetElementPtrInst::Create(ptr1, const_4, “tmp3″, bb);

save, compile, and it runs fine. Of course it’s not the exactly
modification I made, because I built a loop and a switch case to
create many CallInst(s). The exactly lines were:

const_n = ConstantInt::get(APInt(32, lexical_cast<std::string>(step), 10));
ptr = GetElementPtrInst::Create(params.back(), const_n, “tmp”, bb);

You can find the source code at the bottom of previous post.
[LLVM & Rubinius]

Many thanks for your listening and kindness!

cheers,
Lin Jen-Shin (a.k.a. godfat 真常)

p.s. below is another copy of above message.
http://blogger.godfat.org/2008/10/llvm-rubinius-2.html

My work on Ruby and LLVM got sidetracked when I read Ian Piumarta’s papers about Cola (http://piumarta.com/software/cola/). Especially check out the minimal object model (http://piumarta.com/software/cola/). Now I’m spending my time on just enough icing on top of LLVM to build multiple dynamic object models.

How are you planning on implementing closures? Garbage collected stack frames and CPS? Also, the GC interface in LLVM is pretty sweet, you can tag roots with meta info when you create them and have this passed to your GC at collection time.

1) Allowing methods to be written in C, inline. This used the clang project associated with LLVM, plus the LLVM jitter infrastructure. This would also be useful in Ruby. I published a WIP version of that work with VW but it’s not useful in this forum.

2) Using LLVM as you have described, to replace the existing VW jitter and ‘outsource’ most of the platform details to LLVM. Unfortunately you need to be a Cincom commercial customer to get the VM source (I am), and then there’s the problem of how to distribute it. This problem contributed to me putting two of my projects on hold (the other was embedding WebKit with full GC integration). This work wasn’t far enough along to produce results, although as you have seen, results can actually come very easily with LLVM.

You should post the x86 machine code generated from your exampl, because in my experience that’s where the OMG kicks in because those getelementptr lines disappear.

Over the last month I have been looking to restart this work in a Ruby context, because as you’ve discovered LLVM is absolutely the dogs bollocks, and it’s beautifully written and architected. It really could be like standing of the shoulders of giants as far as what it could do for Ruby performance, particularly with, as I mentioned, partial specialisation keyed off something like multimethod dispatch signatures.

One of the nice things that can be done is for nearly all of the work to be done in Ruby, rather than using C. Theoretically you can do the entire thing in LLVM + Ruby, although bootstrapping can be a curly problem.

I’d love to work on this, I’ve just got to get up to speed on the Rubinius architecture.

“This doesn’t allow for inlining across things like the kind of method call that Ruby does” – actually, you can if you implement partial specialisation, which I think could generate enormous wins, especially if you specialise code that dispatches to immediates. It’s like a PIC, but with the code inlined at the call site rather than just caching the method lookup.