Lua 5.1.1 LOADNIL optimization bug (was: What's wrong here?)

[Mike Pall <mikelu-0703@...>]

Hi,

Julien Hamaide wrote:
> When the parser detects an assignment from a local variable to nil, it
> calls luaK_nil() which checks if pc == 0 and skip assignment
> 
> if (fs->pc == 0)  /* function start? */
>       return;  /* positions are already clean */
> 
> is the guilty code
> 
> To get rid of the bug, apply the attached patch to lcode.c

IMHO the patch is wrong. One needs to check that the assigned
variable is a new one and not a parameter. Only then can the
first LOADNILs be omitted. But this requires restructuring ...

The other option is to scrap this micro-optimization entirely.
IMHO it's not going to make any notable difference in speed.

BTW: When this was added during the Lua 5.1 development phase, it
gave me immense trouble with LuaJIT. Because one can no longer
assume that all variables are explicitly initialized. This makes
reasoning about the bytecode more difficult. And some of the
required special cases in the function prologue actually slow
down _all_ functions. :-(

I've commented on this previously:
  http://lua-users.org/lists/lua-l/2005-11/msg00132.html

Alas, removing the (now redundant) branch (*) in luaD_precall would
make the bytecode incompatible between Lua 5.1.1 and Lua 5.1.2.

Time for 5.2? But wait, then I have a few more suggestions ..

[*] This is redundant when the LOADNIL optimization is omitted:
    if (L->top > base + p->numparams)
      L->top = base + p->numparams;

Bye,
     Mike