Re: [ANN] llvm-lua 1.0

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

On Friday 05, Mike Pall wrote:
> > [...] The slow path function would need to
> > be inlined at the end of the fast path function.
>
> Why not save all modified state to the Lua stack and refer the hard
> part to the interpreter? Unlike a JIT compiler, if the static type
> prediction fails, you're pretty much hosed, anyway. You'll not be
> able to considerably improve performance by emitting calls to
> generic operators.

The slow path function is still faster then the interpreter, falling back to 
the interpreter would require fixing up more state since some LOADK ops are 
inlined in as native constant.  But I could still provide an option to allow 
falling back to the interpreter, for people that want a balance between 
performance and code size.

Also one possible use of llvm-lua is code obfuscation since it is possible to 
strip the Lua bytecode from compiled functions (this disables all debug 
support).  In that case it wouldn't be possible to fall back to the 
interpreter.

> > One way to still allow some monkey patching would be to put a
> > proxy-object into the global tables for each of the functions. [...]
>
> I don't think you need to go to these lengths. A dynamic lookup
> during parsing covers 99% of all monkey patching cases (like Mark
> Hamburg's example). A static compiler could just take a list of
> exempt library functions.

A JIT wouldn't need the proxy object, but a static compiler would need it to 
support monkey patching, since the compiler may not be able to detect the 
order of read/writes to the globals.  Also the static compiled code might 
load & run some new Lua code at runtime which does the monkey patches.

-- 
Robert G. Jakabosky