Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
On Fri, Mar 28, 2008 at 3:25 AM, Raymond Hettinger
<[EMAIL PROTECTED]> wrote:
>
> It would be helpful if we talked before going further on build-outs to
> the peephole optimizer.
Sure.
> IIRC, we chose to not do this one because it
> interfered with other more important optimizations.
There are two optimization in my patch: one for +<const> and the other
not <const>. I think you recall that not <const> optimization could
interfere with not a is b --> a is not b and similar transformations.
My patch, however does not affect those. With respect to unary +, I
don't think it was intentionally omitted: I would think it is more
common to use unary + on constants than `..`, but case UNARY_CONVERT
is there in 2.x.
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:
1 0 LOAD_CONST 0 (1)
3 LOAD_CONST 3 (6)
6 BINARY_ADD
7 RETURN_VALUE
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.
> You're writing these faster than I have time to review and likely
> reject them. Please show some moderation.
ok :-) One more peephole optimizer related idea that I have in the
pipeline is to implement an option to disable optimization altogether.
Having such an option would help debugging/profiling the optimizer
and will give users a simple check when they suspect that their code
is improperly optimized. I would propose a patch already, but I
could not think of a good command line option. Most compilers use
-O0, but that would be confusingly similar to -OO. What do you think?
__________________________________
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2499>
__________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
