Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment: For clarifying, this issue doesn't have any relations to the AST optimizer. Tuples of constants are already optimized at the AST level, but there are other tuples created in code, which don't correspond any AST node. They are worth to be optimized too. That is why we need (and have) two codes for folding tuples of constants -- at high level (in AST) and at low level (in generated bytecode).
Different kinds of optimizations can be applied at different stages. 1. On AST. Optimizations applied here are: constant folding (evaluating expressions with unary and binary operators and subscriptions on constants and folding tuples of constants), constant propagation of __debug__, converting "in list/set" into "in tuple/frozenset". 2. At code generation stage. Optimizations applied here are: some special cases for "if" and "while" with a constant condition, optimizing short-circuit jumps in complex boolean expressions, avoiding generating some code (like for "if" without "else"), special case for literal dicts with constant keys, merging equal constants and names. 3. On generated intermediate representation of bytecode (a graph of sequences of instructions). Some unreachable code is eliminated here. 4. On raw bytecode (in peephole.c). Optimizations applied here are: other special cases for "if" and "while" with a constant condition, folding tuples of constants created at code generation stage, special cases for multitarget assignments (1-3 targets), optimizing more short-circuit jumps in complex boolean expressions, replacing jumps to unconditional jumps, removing unreachable code after RETURN_VALUE. 5. In the code object constructor (it is applied also when unmarshal code). Names and identifier-like string constants (including nested in tuples and frozensets) are interned here. PR 6545 moves a particular optimization from stage 4 to stage 3 (to a tiny bit higher level). Issue32477 moves other 2 or 3 optimizations from stage 4 to stage 3. It is possible to move this particular optimization even to stage 2, but I'm not sure that mixing code generation with optimization would look better. At stage 3 it is more isolated. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33318> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
