[Python-ideas] Disable all peephole optimizations

[Victor Stinner]

Hi,

2014-05-21 13:05 GMT+02:00 Ned Batchelder <ned at nedbatchelder.com>:
> A long-standing problem with CPython is that the peephole optimizer cannot
> be completely disabled.

I had a similar concern why I worked on my astoptimizer project. I
wanted to reimplement the peephole optimizer using the AST instead of
the bytecode. Since the peephole optimizer is always on, I was not
able to compare the bytecode generated by my AST optimizer without
peepholer optimizer to the bytecode generated with the peephole
optimizer.

I would also be curious to see the code before the peepholer optimizer
modifies it.

> If you execute "python3.4 -m trace -c -m continue.py", it produces this
> continue.cover file:
>
>     1: a = b = c = 0
>   101: for n in range(100):
>   100:     if n % 2:
>    50:         if n % 4:
>    50:             a += 1
>>>>>>>         continue
>            else:
>    50:         b += 1
>    50:     c += 1
>     1: assert a == 50 and b == 50 and c == 50
>
> This indicates that the continue line is not executed.

I played long hours in gdb and this is a common issue of compiler
optimizations. In gdb, sometimes the program looks to go backward or
reexecute the same instruction twice. I hate loosing my time with
that, I prefer to recompile the whole (C) application with gcc -O0
-ggdb.

> ** User Interface
>
> Unfortunately, the -O command-line switch does not lend itself to a new
> value that means, "less optimization than the default."  I propose a new
> switch -P, to control the peephole optimizer, with a value of -P0 meaning no
> optimization at all.  The PYTHONPEEPHOLE environment variable would also
> control the option.

I propose "python -X nopeephole" , "python -X peephole=0" or "python -X optim=0"

I don't like "python -X peephole=0" because "python -X peephole"
should active the optimizer, which is already the default.

For "optim" proposition, should we keep it synchronous with -O and -OO?

(no -O alternative) <=> -X optim=0
(default) => -X optim=1
-O <=> -X optim=2
-OO <=> -X optim=3

I never understand -O and -OO. What is optimized exactly. To me,
striping docstrings is not really an "optimization", it should be a
different option.

Because of this confusion, the peephole optimizer option should maybe
be disconnected to -O and -OO. So take "python -X nopeephole".


IMO you should not write .pyc or .pyo files if the peephole optimizer
is actived. It avoids the question of "was this .pyc generated with or
without peephole optimizer?". Usually, when you disable optimizations,
you don't care of performances (.pyc are created to speedup Python
startup time).


I also suggest to add a new flag to the builtin compile() function:
PyCF_NO_PEEPHOLE.

> There are about a dozen places internal to CPython where optimization level
> is indicated with an integer, for example, in Py_CompileStringObject.  Those
> uses also don't allow for new values indicating less optimization than the
> default: 0 and -1 already have meanings.  Unless we want to start using -2
> for less that the default.  I'm not sure we need to provide for those
> values, or if the PYTHONPEEPHOLE environment variable provides enough
> control.

Add a new flag to sys.flags: "peephole" or "peephole_optimizer"
(boolean, True by default).

Victor