I finally implemented my suggestion for the switch elimination.
On top of threadedceval5.patch, apply abstract-switch-reduced.diff and
then restore-old-oparg-load.diff to test it.

This way, only computed goto's are used. I would like who had
miscompilation problems, or didn't get advantage from the patch, to try
compiling and benchmarking this version.

I've also been able to reenable static prediction (PREDICT_*) on top of
computed gotos, and that may help CPU prediction even more (the BTB for
the computed goto will be used to predict the 2nd most frequent target);
obviously it may instead cause a slowdown, I'd need stats on opcode
frequency to try guessing in advance (I'll try gathering them later
through DYNAMIC_EXECUTION_PROFILE).

Apply reenable-static-prediction.diff on top of the rest to get this.

I'll have to finish other stuff before closing everything to run
pybench, I can't get stable timings otherwise, so it'll take some time
(too busy, sorry). However I ran the check for regressions and they show
none.

====
abstract-switch-reduced.diff is the fixed abstract-switch.diff -
actually there was just one hunk which changed the handling of f_lasti,
and that looked extraneous. See the end of the message.

--- a/Python/ceval.c    Thu Jan 01 23:54:01 2009 +0100
+++ b/Python/ceval.c    Sun Jan 04 14:21:16 2009 -0500
@@ -1063,12 +1072,12 @@
                }

        fast_next_opcode:
-               f->f_lasti = INSTR_OFFSET();

                /* line-by-line tracing support */

                if (_Py_TracingPossible &&
                    tstate->c_tracefunc != NULL && !tstate->tracing) {
+                       f->f_lasti = INSTR_OFFSET();
                        /* see maybe_call_line_trace
                           for expository comments */
                        f->f_stacktop = stack_pointer;