Re: [ANN] llvm-lua 1.0

["Robert G. Jakabosky" <bobby@...>]

On Friday 05, Alexander Gladysh wrote:
> We use Lua built as .so. Is this fine with llvm-lua?

I just checked in a change to the Makefiles that will build a liblua-llvm.so 
file.  LLVM must be compiled with PIC support (configure 
option "--enable-pic" which is turned on by default now, but was always).  I 
had to re-compile LLVM to get PIC support on my system.

I don't know if LLVM supports being compiled as shared libraries.  The default 
seems to be to only build static libs.  This means that the host application 
needs to be statically linked to some of the LLVM libs, this adds about 
9Mbytes (about 90Mbytes if you compiled LLVM with debug info) to the binary 
size.

Here is how to compile llvm-lua/etc/min.c with JIT support:
gcc -o etc/min.o -c etc/min.c
g++ -o etc/min etc/min.o -llua-llvm `llvm-config --ldflags --libs core jit 
native linker` -rdynamic -Wl,-E -lm -ldl

Make sure to not leave out "-rdynamic -Wl,-E" that is required by the JIT to 
link the JITed lua functions to the functions in the Lua core.

> >> > Right now that one instance of LLVMCompiler is shared by all
> >> > lua_States, I might move the global variable to a member variable of
> >> > 'lua_State' .  A lock on that shared instance might still be the best
> >> > option.  I will look into this for the next release.
>
> Perhaps it is better to be left configurable -- there are probably
> uses for either of options.

Using a lock would require linking llvm-lua with pthreads or some other thread 
library.  I might add the lock method as a configurable option later.  It 
would also be good to support the global one instance of LLVMCompiler for 
people that need to create lots of lua_State's but only use them all in one 
thread.

-- 
Robert G. Jakabosky