Re: Subject: [ANN] Lua 5.5.1 (rc1) now available

On Friday, 17 July 2026 22:38:36 EEST 'Martin Eden' via lua-l wrote:
> On 2026-07-15 22:53, Luiz Henrique de Figueiredo wrote:
> > Lua 5.5.1 (rc1) is now available for testing at
> > https://www.lua.org/work/lua-5.5.1-rc1.tar.gz
> 
> Congratulations with release! (I still admire your admittance of bugs.)
> 
> Lua 5.5.1 (as many previous versions) sometimes produces bytecode
> with unreachable instructions. (At least I don't understand
> how they can be reached.)
> 
> For example "local f = function() end; return f;":
> 
>    > $ echo 'local f = function() end; return f;' | luac -p -l -s -
>    >
>    > main <stdin:0,0> (4 instructions at 0x5626f1974b30)
>    > 0+ params, 2 slots, 1 upvalue, 1 local, 0 constants, 1 function
>    >   1 [1] VARARGPREP  0
>    >   2 [1] CLOSURE   0 0 ; 0x5626f1974e20
>    >   3 [1] RETURN    0 2 1 ; 1 out
>    >   4 [1] RETURN    1 1 1 ; 0 out
>    >
>    > function <stdin:1,1> (1 instruction at 0x5626f1974e20)
>    > 0 params, 2 slots, 0 upvalues, 0 locals, 0 constants, 0 functions
>    >   1 [1] RETURN0
>    >
> 
> "RETURN 1 1 1" looks unreachable and dead code.
> 
> (I understand that's code generation quirk and code generation
> is not simple thing.)
> 
> I hope dead bytecode will be reduced in future Lua versions.
> 
> -- Martin
> 
> 
> --
> You received this message because you are subscribed to the Google Groups
> "lua-l" group. To unsubscribe from this group and stop receiving emails
> from it, send an email to [email protected]. To view this
> discussion visit
> https://groups.google.com/d/msgid/lua-l/7a3bc6d6-84e5-445d-80f4-d0c800aab0c
> 8%40disroot.org.

AFAIK the lua compiler is made to be as dumb and simple as possible, so it can 
be as fast as possible. Hence, no CFG and SSA analysis exists, which are the 
only reliable methods of eliminating dead code paths.

On another side, the dead path you're seeing is the lua compiler putting a 
virtual "return" statement on the end of the chunk. I presume this is done so 
that a bound check in the VM loop is avoided, as the VM loop is a quite 
critical section of the lua interpreter.

A tool that does said CFG optimizations on the lua bytecode level could quite 
easily be made IMHO, it is a matter of building a node of instructions and 
"shaking" it, and finally reconstructing it. However, 1. the compiler never 
actually runs those instructions, so they don't impede performance, and 2. the 
amount of dead code is negligible, so memory concerns are irrelevant here as 
well.




-- 
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/lua-l/pVGcXvSDQni0SiOsr-T84A%40topcheto.eu.