A minor difference is that strings and whitespace are parsed according to LSL rules, not to C rules, since this processing is performed in the lexer.
This could be fixed, but is it worth the trouble?
Includes PCPP as a submodule (which in turn pulls PLY as a submodule, so be sure to initialize submodules recursively). Also includes a file to interface PCPP with the optimizer, patching its behaviour according to our needs.
Special thanks to Niall Douglas and David Bezley for authoring PCPP.
This is a first try at redundant jump removal (jumps that target the very next instruction). It's too basic in several ways.
- The statement is replaced by a ';' instead of removed.
- If the jump was the only statement in an if, when the if becomes empty, it's not folded.
- Jumps that are last in the 'then' branch of if+else are not visible. This would need either to track multiple last statements, or to have some means to anticipate what the next statement is at every statement. A Control Flow Graph would help a lot.
- When a label is immediately followed by a jump, all jumps to that label should target the destination of that jump if it's in scope. Added to TODO.
- It misses some optimizations when not expanding WHILE and FOR into IF/JUMP.
Moving everything to an earlier stage would help with some of these, especially with ';' and 'if' folding. Unconditionally expanding WHILE and FOR would also help.
We already report the differences even in diff format, and the scripts can get long. The output of assertEqual was not useful, therefore it's eliminated.
This test suite has been in use for a long time now, in place of the obsolete and unmanageable testparser.py and testfuncs.py. It verifies the complete optimizer output to stdout and stderr, to ensure that the output matches the expectations.
See unit_tests/README.txt for more info.
SymbolReplacedOrDeleted had an "emergency fix" that disabled several kinds of substitutions, because they generated code that didn't compile. The cause was actually elsewhere.
The actual problem was the marking of function parameters as being written to by function calls. This is true in a sense, but there's a big scope change that totally destroys the possibility of substituting identifiers, for example.
We were not removing the function parameters, anyway, therefore that code has just been disabled.
Note that removal of function parameters may be impossible if one parameter has side effects. Consider this:
f(string x, integer y, string z)
{
llOwnerSay(x + z);
}
integer n = 2;
default{state_entry(){
f("a" + (string)n, n=llSetRegionPos(<100,100,100>), "c" + (string)n);
}}
Even worse if the expression for the x argument has side effects too and x and y need to be performed in the right order.
Fortunately, such case is highly unlikely. But if we ever implement removal of function parameters, that's an additional difficulty to take care of.
This allows optimizing, for example:
integer a = 1;
integer b = a;
llOwnerSay((string)b);
which wasn't done before. This case is prone to happen with inlined functions, e.g. using the result of an inlined function as a parameter to another.
It was an awful name but we couldn't think of anything better. That's what we have come up with as a substitute, which is not entirely accurate but it is MUCH more descriptive of what it actually does.
It's set in a variable local to that module. There's currently no way to enable it except by editing the code, but since it's mostly for internal purposes, it's OK like that.
