On 5/21/14 8:17 PM, Eric Snow wrote:
* Over time, I expect that some of the functionality of the peepholer
is going to be moved upstream into AST transformations you will have even less ability switch something on-and-off.
I'm perfectly happy to remove the word "peephole" from the feature. If we expect the set of optimizations to grow in the future, then we can expect that more cases of code analysis will be misled by optimizations. All the more reason to establish a way now that will disable all optimizations. While the use-case is very specific, I think it's a valid motivator for a means of disabling all optimizations, particularly if disabling optimizations is isolated to a very focused location as you've indicated.
The big question then is the impact on implementing optimizations (in general) in the future. There has been talk of AST-based optimizations. Raymond indicates that this makes it harder to conditionally optimize. So how much harder would it make this future optimization work? Is that a premature optimization? <wink>
I don't understand the claim that AST transformations will have less ability to switch something on-and-off. The very term "AST transformations" outlines the implementation: step 1, construct an AST; step 2, transform the AST; step 3, generate code from the AST. My proposal is that a switch would let you skip step 2. This is analogous to the current optimizer, which generates bytecode, then as a separate (and skippable!) step, performs peephole optimizations on that bytecode. --Ned.