[Types-sig] Low-hanging fruit: recognizing builtins

[Tim Peters]

[Guido]
> ...
>           LOAD_GLOBAL         0 (len)
>           LOAD_FAST           0 (a)
>           CALL_FUNCTION       1

vs

> can be replaced by
>
>           LOAD_FAST           0 (a)
>           UNARY_LEN
>
> which saves one PVM roundtrip and two dictionary lookups, plus the
> argument checking code inside the len() function.

To get the latter, I believe we'd need to write an additional len()
function.  That is, the current checking len has to stick around to deal
with stuff like

    apply(f, args)

when f happens to be bound to __builtin__.len.

> There are plenty of bytecodes available.

Likely many more than there are compilers that can tolerate another case in
eval_code2's switch <wink>.

> ...
> The per-module analysis required is major compared to what's
> currently happening in compile.c (which only checks one function
> at a time looking for assignments to locals) but minor compared
> to any serious type inferencing.

Note too that it's a length-changing transformation, which is also brand
new.  That is, the only optimizations in compile.c now replace a bytecode
with another of the same size.  So (at least) jump offsets and the
line-number table would need to be recomputed too.

Not hard, there's simply no machinery there to build on now.

OTOH, compile.c needn't be involved; the analysis & transformations *could*
be done via a bytecode-fiddling Python program.

i-knew-michael-hudson-would-be-useful-for-*something*<wink>-ly y'rs  - tim