Re: Optimizing off-line Lua compiler

[Luiz Henrique de Figueiredo <lhf@...>]

Sure, luac could do optimizations. In Lua 4.0 and previous versions, it
did. However, bytecode editing wasn't pretty (though it was a little fun).
The current internal compiler does several optimizations, but aims only for
the easy or frequent cases. The trade-off seems good.

If you can identify patterns in the bytecode that can be optimized, then
they can probably be added to the internal compiler. Please let us know if
you find any such patterns. However, there's a limit to what such peephole
optimizations can do. Once you reach this limit, the only way to optimize
code is to do global analysis and this cannot be really done if you only
have the source code. So, you'd need a different parser and code generator
for luac, something that we probably do not want to maintain, to ensure
consistency.

Finally, there's the question of why do this. Isn't Lua fast already?
What kind of Lua code would benefit from additional bytecode optimization?
--lhf

PS: As I see it, the road to ensuring consistency of the language tools
is to reuse the code from the Lua core. The lexer is easy to reuse -- and
I have been advocating this here for a while. I wish the parser was easy
to reuse, but unfortunately, it's not, even though in theory you could
just plug in another parser and code generator because there is only one
entry point to the parser. Actually, this is a path to reusing the lexer:
just plug in another "parser". I'll talk about this at the workshop. This
is a place where some optimizations could be done, say by defining named
constant in the code. But this of course changes the language...