[issue26300] "unpacked" bytecode

STINNER Victor added the comment: > The "peephole" optimizer now operates on the internal IR, not the bytecode. Python/ast_opt.c is cool ;-) Thanks INADA-san for creating it! -- ___ Python tracker _

[issue26300] "unpacked" bytecode

Mark Shannon added the comment: PEP 511 was rejected. The "peephole" optimizer now operates on the internal IR, not the bytecode. -- nosy: +Mark.Shannon resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

[issue26300] "unpacked" bytecode

Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue26300] "unpacked" bytecode

Changes by Brett Cannon : -- nosy: +brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue26300] "unpacked" bytecode

Andrew Barnert added the comment: Reading more about wpython (slide 23 of https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/wpython2/Cleanup%20and%20new%20optimizations%20in%20WPython%201.1.pdf), one of his optimizations was moving the peephole optimizer into the c

[issue26300] "unpacked" bytecode

New submission from Andrew Barnert: Currently, the compiler starts with a list of arrays of instructions, packs them to 1/3/6-bytes-apiece bytecodes, fixes up all the jumps, and then calls PyCode_Optimize on the result. This makes the peephole optimizer much more complicated. Assuming PEP 511