Re: Question about SETFIELD nil emission in table constructor codegen

Not really: a table literal can be copied/instantiated much faster without
using Lua bytecode interpretation; this depends only on the Lua compiler
implementation used.

Consider also this code:

local x, y
function f() return {x, y} end
x = 1, y = 2
local A = f()
local B = f()
x = 3, y = 4
local C = f()

Note that there's also a pseudo-literal table constructor in f() which is
bound in scope to a closure starting with the context where local x and y
are defined: is that code supposed to return the same literal?
* Maybe for A and B (where A[1]==B[1]==1 and A[2]==B[2]==1).
* But then look at C, the values of x and y have changed when f() is
called, so C[1]=3, C[2]=4.
* This means that each function call must instantiate a separate table;
however the compiler could still construct a hidden literal for {x,y},
bound to the closure where x,y are defined, using accessors: the
instantiation would still need to replace the references to x,y by their
effective value, and in that case it's just simpler to generate the code
that builds {x,y} with normal Lua evaluations.

The optimization using constant pools is possible only if the table
constructor does not depend on external variables or on local variables
whose values are not constant within the function making the instantiation.
This requires data flow analysis by the compiler (something the the
standard Lua compiler will probably never do, but that optimized Lua VM
implementation may want to perform to detect when optimizations are
possible, like the extreme optimizations made in modern Javascript engines;
for now it is not a goal of the reference Lua compiler, but it is trivial
for strings and scalars, and for table constructors containing only strings
and scalars (something that is very frequent in many Lua projects that
contain lot of constant lookup tables, e.g. tables generated for finite
state machines, or stable reference datasets or geometric models,
historical datasets defined in reusable Lua modules and libraries).

Le dim. 1 mars 2026 à 12:35, Luiz Henrique de Figueiredo <
[email protected]> a écrit :

> > Concerning literal tables, I've always asked myself why the compiler
> does not build table literals with only constant members at compile time
> and stores them in a constant pool, as it already does for strings and
> scalars.
>
> Consider this code:
>
> function f() return {1,2,3} end
> A=f()
> B=f()
>
> With your proposed scheme, A and B would get the same table, not two
> different tables with the same contents.
> If the runtime needed to create copies of table literals then the
> executed code would be much the same.
>
> --
> 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/CABt16q%3De91C3UbXMPMOe6mbKiCTzK56tUaA9FKfFqNC-EgK%3Dow%40mail.gmail.com
> .
>

-- 
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/CAGa7JC1kOjbkhPORkygg0OFjVMO%3DyMzWoftb%2BccmMdrK2fwxXA%40mail.gmail.com.