[LLVMdev] Scheme + LLVM JIT

[Andrew Lenharth]

On Wed, 2005-05-04 at 23:59 -0400, Alexander Friedman wrote:
> Hi List,
> 
> I am in the preliminary stages of adding a JIT compiler to a sizable
> Scheme system (PLT Scheme). The original plan was to use GNU
> Lightning, but 1) it seems to be dead, and 2) LLVM has already done a
> huge amount of stuff that I would have had to write (poorly) from
> scratch.

Yay!  A real language :)

>  Explicitly managed stack frames would also be nice, but are not a
>  necessity unlike the mixed calling conventions and tail call
>  elimination. For all of you who are wondering about call/cc, we
>  currently implement it via stack copying (and will continue to), so I
>  am not worried about llvm not having a representation for
>  continuations.

Mixed calling conventions are on a lot of people's list of things they
want to see.  The only mixed calling convention hack I know of is in the
Alpha backend to avoid indirect calls and some prologue.  However this
is just a single arch's hack.  Work on the general case would probably
receive a fair amount of interest and support.

> JIT + Optimization interactions:
>  To be more precise, does the JIT perform all of the standard llvm
>  optimizations on the code, or does it depend on it's client to do so
>  himself? Are there some examples of that?

So as it stands, one should think of out JIT as something akin to the
early Java JITs:  one function at a time and only one compile per
function.  This is extremely primative by modern JIT standards, where a
JIT will do profiling, find hot functions and reoptimize them,
reoptimize functions when more information about the call tree is
available, have several levels of optimizations, etc.

There isn't, AFAIK, anything stopping a user of the JIT from doing much
of this work, however it would be nice to improve the JIT.

> C-Interface:
> 
>  Does there happen to be a C interface to the jit ? Our scheme impl
>  has a good FFI, but it doesn't do C++. If not, this is no big deal,
>  and i'll just write something myself.

No, but such bindings would be *very useful*.  And since there might be
other people who need them this summer, such work might also get a lot
of help.

> Size of Distro/ Compilation Speed
> 
>  While the sources of llvm are not that big, the project builds very
>  slowly into something very large. Someone already asked about what is
>  the minimum needed for just a JIT compiler, and I think I have a
>  vague idea of what needs to tweaked. However, I want to minimize the
>  changes I make to my llvm tree. I know that no one can make g++ run
>  any faster, but part of the speed problem and resulting size of the
>  compilation is that the configure script seems to ignore my
>  directives. For examle, it always builds all architectures, and it
>  always statically links each binary.

See misha's comment about some new build flags.  Also, things are
considerably smaller (an order of magnitude) if one makes a release
build (make ENABLE_OPTIMIZED=1)

> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
-- 
Andrew Lenharth <alenhar2 at cs.uiuc.edu>
-- 
Andrew Lenharth <andrewl at lenharth.org>