Re: Lua 5.1.1 LOADNIL optimization bug

[Julien Hamaide <julien.hamaide@...>]

Mike Pall wrote:
> 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.

In some ways, I've scrapped this micro-optimization when LOADNIL is
first instruction with the patch, while keeping it for other case. I
don't understand what's the difference with your solution.

Sorry



> 
> 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
> 
> 


-- 
--
Julien Hamaide
Engineering Coach
10Tacle Studios Belgium / Elsewhere Entertainment