[Venkatraman S]
the following line kind of confuses me and wasnt sure what exactly Raymond(et al) is planning,
I think the AST optimization work is being pursued by tlee. See his current results on the branch: tlee-ast-optimize/ I don't know if this work has stalled but it was off to a good start.
as i presume that bytecode optimizations are much _easier_ than optimizations in AST. . . . "Most of the peepholer is going to be migrated up the chain, after the AST is generated, but before the opcodes are generated."
I don't think your presumption is true. For some transformations (especially constant folding), more is possible with AST than with bytecode. We won't know for sure until the work is done and there is a good, working patch. Right now, the peepholer is limited by basic blocks, by only rewriting opcode sequences that are same or shorter size, and has to do tricks like writing-out NOPs and the eliminating them while rewriting the jump targets. Essentially, it disassembles fragments, analyzes them, and reassembles them. Better to start before the assembly, do the AST rewrites, and then less the existing assembler do its thing. When it comes to optimizing long fragements and extended args, the peepholer punts and does nothing. All of this makes it tightly bound to a given set of opcodes and everything must be re-evaluated whenever someone proposes a new opcode or changes the meaning of the existing code.
If there are some optimizations that can be done in the bytecodes, then 'where' would be the suggested place to incorporate the same;
The "where" is being developed. Your help would be welcome.
as i also see that some of the more rudimentary optimizations have been rejected in many of the patches.
A number of patches have been accepted. The ones that were rejected were either too complicated, interfered with other optimizations, or did too much work for too little payoff (i.e. deadcode elimination which costs compilation time but doesn't actually speedup code). Raymond