[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] llvm-lua 1.0
- From: "Robert G. Jakabosky" <bobby@...>
- Date: Sat, 6 Jun 2009 21:39:40 -0700
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
> > 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