Unsound in a very specific and suspicious way - yesterday it was pointed out adding a single, do-nothing, line to the middle of the function makes the "optimizer" fail.
That isn't unsoundness, that's incompleteness. An optimization being incomplete means that something that could be optimized isn't -- one being unsound means that something that shouldn't be optimized is. These terms come from mathematical logic.
Sorry. I am an engineer. I got it as "not solid", "wrong", "flaky". I appears all three apply perfectly to the optimizer at hand. Being it both unsound (as it optimizes too much of a benchmark) and incomplete (as it doesn't recognize the invalidity of the code being optimized - the Angles thing - and fails to optimize too much when a no-op is added) we could just be more concise and settle for "broken".
I think you're still mixing up what "unsound" means. If I say that applying an optimization is unsound, it means that if I apply that optimization, I can no longer guarantee that the resulting code is semantically equivalent to the original code.
Being incomplete means the code you generate is not as fast as possible. Being unsound means the code you generate may be wrong. We don't normally call an optimizer "broken" if it does not optimize something even though we can recognize the optimization could be applied - no optimizer does every conceivable thing. But generated code that is not semantically equivalent to what was given violates correctness.
I think the "Angles" removal demonstrates the optimization is unsound. The "optimized" code gives out a result when a correctly optimized one would give a ReferenceError. This optimizer ignores invalid code (that references a non-existent thing) and happily short-circuits it.
The only reason to trust this code to do other optimizations well is all the evidence it's targeted at one specific benchmark.
Comments
Unsound in a very specific and suspicious way - yesterday it was pointed out adding a single, do-nothing, line to the middle of the function makes the "optimizer" fail.
That isn't unsoundness, that's incompleteness. An optimization being incomplete means that something that could be optimized isn't -- one being unsound means that something that shouldn't be optimized is. These terms come from mathematical logic.
Sorry. I am an engineer. I got it as "not solid", "wrong", "flaky". I appears all three apply perfectly to the optimizer at hand. Being it both unsound (as it optimizes too much of a benchmark) and incomplete (as it doesn't recognize the invalidity of the code being optimized - the Angles thing - and fails to optimize too much when a no-op is added) we could just be more concise and settle for "broken".
I think you're still mixing up what "unsound" means. If I say that applying an optimization is unsound, it means that if I apply that optimization, I can no longer guarantee that the resulting code is semantically equivalent to the original code.
Being incomplete means the code you generate is not as fast as possible. Being unsound means the code you generate may be wrong. We don't normally call an optimizer "broken" if it does not optimize something even though we can recognize the optimization could be applied - no optimizer does every conceivable thing. But generated code that is not semantically equivalent to what was given violates correctness.
I think the "Angles" removal demonstrates the optimization is unsound. The "optimized" code gives out a result when a correctly optimized one would give a ReferenceError. This optimizer ignores invalid code (that references a non-existent thing) and happily short-circuits it.
The only reason to trust this code to do other optimizations well is all the evidence it's targeted at one specific benchmark.