On Sun, 2011-01-02 at 19:18 -0800, Guido van Rossum wrote:
> On Sun, Jan 2, 2011 at 5:50 PM, Alex Gaynor <alex.gay...@gmail.com> wrote:
> > No, it's singularly impossible to prove that any global load will be any 
> > given
> > value at compile time.  Any optimization based on this premise is wrong.
> 
> True.
> 
> My proposed way out of this conundrum has been to change the language
> semantics slightly so that global names which (a) coincide with a
> builtin, and (b) have no explicit assignment to them in the current
> module, would be fair game for such optimizations, with the
> understanding that the presence of e.g. "len = len" anywhere in the
> module (even in dead code!) would be sufficient to disable the
> optimization.
> 
> But barring someone interested in implementing something based on this
> rule, the proposal has languished for many years.

Is there a PEP for this?

> 
> FWIW, this is reminiscent of Fortran's rules for "intrinsics" (its
> name for builtins), which have a similar optimization behavior (except
> there the potential overrides that the compiler doesn't need to take
> into account are load-time definitions).

I've been attempting another way in:
  http://bugs.python.org/issue10399
using a new "JUMP_IF_SPECIALIZABLE" opcode.  This compares what a value
is against a compile-time prediction, branching to an optimized
implementation if the guess was correct.  I use this to implement
function-call inlining within the generated bytecode.

Caveat-of-doom: That code's very much a work-in-progress at this stage,
though: sometimes it doesn't segfault :) and the way that I track the
predicted values is taking some other liberties with semantics (see that
URL and the dmalcolm-ast-optimization-branch in SVN).

(There's probably at least 2 PEPs in the above idea, though have yet to
write my first PEP)

Hope this is helpful
Dave

_______________________________________________
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

Reply via email to