Constant folding does not work when variable is used in multiple vectors

[KrsityKu]

In the following code:

default
{
	touch_start(integer total_number)
	{
		float val = 1.0;
		vector vec1 = <val + val, 0, 0>;
		vector vec2 = <val + val, 0, 0>;
		llOwnerSay((string)vec1);
		llOwnerSay((string)vec2);
	}

	touch_end(integer total_number)
	{
		float val = 1.0;
		vector vec1 = <val + val, 0, 0>;
		llOwnerSay((string)vec1);
	}
}

touch_start does not fully fold the constants:

default
{
	touch_start(integer total_number)
	{
		float val = 1.;
		vector vec1 = <val + val, 0, 0>;
		vector vec2 = <val + val, 0, 0>;
		llOwnerSay((string)vec1);
		llOwnerSay((string)vec2);
	}

	touch_end(integer total_number)
	{
		vector vec1 = <2., 0., 0.>;
		llOwnerSay((string)vec1);
	}
}

Options used: Constant Folding and Dead Code Removal. (In the online version of the optimizer)

Expected: both vec1 and vec2 should resolve to <2., 0., 0.>

[Sei-Lisa]

Indeed it doesn't. Just another proof of how the DCR module sucks. I never got to spending the effort to replace it with something that doesn't suck so much.

The whole optimizer will become obsolete once the new Luau engine is the default, so I don't think this is worth fixing.

[KrsityKu]

The whole optimizer will become obsolete once the new Luau engine is the default, so I don't think this is worth fixing.

That is still some unknown time away. Also, since LSL running on Luau engine will be a thing for quite a while and depending on how good the Luau compiler is at constant folding, dead code removal, constant string concatenation, parts of the optimizer might still be quite a useful to use in combination with the preprocessor.

For example: #define STR_STARTS_WITH(str, prefix) (llGetSubString(dstr, 0, llStringLength(prefix) - 1) == prefix) this is quite a handy macro, and when using with const prefix, those length function calls fold in quite nicely.
We don't know just yet, how well LSL on Luau will do things like that.

Also, there's likely to be new LSL functions before Luau stuff shows up, like Combat2 stuff that went live recently, some more notecard related stuff is coming soon too etc.

That being said, the LSL Optimizer is great, don't write it all off just yet, I think it will still be plenty useful until we get native Luau scripts.

[Sei-Lisa]

Thanks for your opinion. I'm not going to redesign the DCR module at this point, which is needed to fix this, especially given that the main blocker for that redesign is that it has the potential to produce larger code instead of shorter, due to Mono save/restore code injection, an issue which would automatically be solved with Luau.

True, no matter how well Luau optimizes, I seriously doubt it will apply function semantics to the optimizations (e.g. it won't resolve llStringLength(constant) to an integer constant like in your example). So yes, there's clearly a benefit in applying source-level optimization. But it must be one that is specifically designed for Luau. It would make sense to have a Luau-specific optimizer that avoids the Mono-specific optimizations that may become counter-productive in Luau. Unfortunately, analysis of Luau bytecode will become much harder now that the Luau code generator is closed-source and that the bug that leaked sim memory (which allowed me to analyse Mono bytecode) is fixed.

As a side comment, llGetSubString produces a new object (= more garbage and possibly more runtime). You can avoid that by doing STR_STARTS_WITH this way: (! llSubStringIndex(str, prefix)).

[KrsityKu]

Unfortunately, analysis of Luau bytecode will become much harder now that the Luau code generator is closed-source

It will be open source, from SUG meeting a while back:

[2024/07/16 12:15:50] Kristy Aurelia: Once we get Lua, any chance of making Lua bytecode visible (read only)? There are currently a lot of various tricks and hacks used to make LSL scripts use less memory, it would make it way easier to figure out which of them still apply on Lua and which can be dropped etc.
[2024/07/16 12:16:25] Signal Linden: Kristy, the compiler will be open source so you will be able to regurgitate the bytecode and examine it
[2024/07/16 12:17:20] Kristy Aurelia: will the LL version of it will be open source? Or just the general version LL is basing their implementation on?
[2024/07/16 12:17:33] Signal Linden: The LL version will be open source

Edit: I guess that doesn't specify if it is for native Luau or for LSL on Luau...