Constant-folding and dead-code elimination are not working correctly on agni
complete
Tapple Gao
The compiler on agni is not doing as much constant-folding and dead-code elimination as the CLI tools. Take this script:
print(gcinfo())
local a = "a" .."a".."a".."a".."a".."a".."a".."a".."a".."a"
.."a".."a".."a".."a".."a".."a".."a".."a".."a".."a".."a"
print(gcinfo())
Variable
a
should be constant-folded away, then eliminated as dead code, as it is unusedOn simulator version Luau 2026-01-30.21516666911 , this prints
[4:29 PM] Object: 1.4892578125
[4:29 PM] Object: 1.525390625
The two numbers are different, so something entered memory in-between the two gcinfo calls
However, when run locally, it prints:
$ ./slua memtest.luau
38
38
The two numbers are the same, indicating nothing happened in memory in-between the two calls.
Looking at the bytecode compiled locally:
$ ./slua-compile memtest.luau
Function 0 (??):
1: print(gcinfo())
GETIMPORT R0 1 [print]
GETIMPORT R1 3 [gcinfo]
CALL R1 0 -1
CALL R0 -1 0
4: print(gcinfo())
GETIMPORT R0 1 [print]
GETIMPORT R1 3 [gcinfo]
CALL R1 0 -1
CALL R0 -1 0
5:
RETURN R0 0
nothing at all happens in between the two print statements. No allocation, no string concatenation, nothing
I can't grab the bytecode for the simulator-compiled script, but it's clearly doing something differently
Log In
H
Harold Linden
marked this post as
complete
Thanks for the report! Looks like it was incidentally fixed by upgrading to a newer Luau.
Fizz Savira
Harold Linden I did some testing today. First, enabling optimization level 2 will cause my 48 long concatenation of string uuids into a single string to be optimized. Level 1 doesn't do it, no idea how that's supposed to work.
HOWEVER. If I enable optimization level 2 in my hud code, it will fail to compile badly. I end up having to comment out more code (I gave up after I figured out that optimization level was the issue). File a new bug? Let me know!
Tapple Gao
Fizz Savira yes, please file a bug if optimization causes something to fail to compile
H
Harold Linden
Tapple Gao Fizz Savira: That's just the nature of the optimization levels in Luau unfortunately. Optimization level 2 tries to optimize for _speed_, not necessarily size, and can / will join strings in a way that pushes you over the memory limit.
There's a case for having more granular optimization options, but I'd want to check with Luau upstream to see if they have any appetite for that.
SuzannaLinn Resident
The issue with not optimizing things containing .. looks solved in Luau 2026-03-24.23471922914 on Aditi
One example:
print(ll.GetUsedMemory()) -- > 2252
local a = "a" .. "a"
print(ll.GetUsedMemory()) -- > 2252
Another example:
print("hello world")
print(ll.GetUsedMemory()) -- > 2288
local a = "hello" .. " world"
print(a)
print(ll.GetUsedMemory()) -- > 2288
Tapple Gao
SuzannaLinn Residentconfirmed. It does seem fixed on aditi. Will have to see what Fizz says once she can log on
It also now behaves different under different optimization levels:
--!optimize 1
print(ll.GetUsedMemory())
local a = "a" .."a"
print(ll.GetUsedMemory())
prints
--!optimize 1
2285
2285
or
--!optimize 0
2314
2332
WolfGang Senizen
The optimizer is enabled and does "work" it seems that some optimizations themselves are not being performed.
--!optimize 0
local a = false
if a then
print("AAAAAAAAAAAAAAAAAAAAAAAAAAAA")
end
print(ll.GetUsedMemory())
Prints
1453
--!optimize 1
local a = false
if a then
print("AAAAAAAAAAAAAAAAAAAAAAAAAAAA")
end
print(ll.GetUsedMemory())
Prints
1390
Not having the optimize directive comment also prints
1390
implying the default is at level 1However some optimizations do not seem to be occuring, for instance
local a = "a"
.."a"
.."a"
.."a"
.."a"
.."a"
.."a"
.."a"
.."a"
.."a"
.."a"
.."a"
.."a"
.."a"
.."a"
.."a"
.."a"
.."a"
.."a"
.."a"
.."a"
print(ll.GetUsedMemory())
Prints
1541
, regardless of optimization level.however compiling this with slua locally using the binaries the
a
variable is removed.