On Sat, Mar 12, 2011 at 1:08 PM, Raymond Hettinger
<raymond.hettin...@gmail.com> wrote:
> I would like to withdraw my suggestion for the recursive constant folding
> patch to be reverted.
So what is the status of peephole optimization now? Is it back under
active development? Let me quote a tracker comment that I posted two
years ago and go no response to ('>'-quote are from Raymond's
message):
"""
Constant folding promotes more readable code: 24*60*60 is more obvious
than 86400, prefixing positive numbers with + leads to better visual
alignment, etc. Users should not be required to think twice about
which constant expressions are folded and which are not.
Here is another surprise with the current peepholer:
>>> dis(lambda:1+2*3)
1 0 LOAD_CONST 0 (1)
3 LOAD_CONST 3 (6)
6 BINARY_ADD
7 RETURN_VALUE
>>> dis(lambda:2*3+1)
1 0 LOAD_CONST 4 (7)
3 RETURN_VALUE
I have a fix in the works, but I will wait for your further comments
before submitting it.
>
> More importantly, we decided that the peepholer is the wrong place to
> do much of this work. Most of the peepholer is going to be migrated
> up the chain, after the AST is generated, but before the opcodes are
> generated. That is a faster, more reliable, and more general
> approach.
>
I agree. Constant folding, is an interesting case because peepholer
has to duplicate a subset of eval logic. I wonder if the new approach
could eliminate that.
BTW, what is the rationale for leading +/- not being part of the
number literal? Unary +/- optimization seems mostly useful for the
simple +/-x case which could be handled by the tokenizer.
What is the timeline for that project? Maybe a comment should be
placed in peephole.c explaining that there is a plan to move
uptimization logic up the compilation chain and announcing a
moratorium on further peephole.c work. I am not the only one
submitting peephole optimizer patches recently.
""" http://bugs.python.org/issue2499#msg64638
I understand that the constant folding pass for AST is the subject of
http://bugs.python.org/issue1346238. The first patch in that issue is
more than four years old. Is that an indication that optimizing AST
is actually harder than optimizing bytecode?
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
