Re: byte-code optimizations

[Richard Stallman <rms@gnu.org>]

    However, we (actually Stefan) need to decide whether we want to try
    optimizing unbinds without visible bindings.  I.e. I'm optimizing

	    varbind-X ... unbind-N --> discard ... unbind-(N-1)

    while Stefan suggests a more general

	    ... unbind-1 --> unbind-1 ...

    which is then followuped by other (existing) optimizations.

The way to decide this is to look at what the results would be in
various cases.  Simply doing the unbind-1 earlier is not a significant
improvement; it does not make the code smaller or faster.  As far as I
can see, the only way it achieves a benefit is if it leads to
eliminating the unbind-1.  That would only happen if Stefan's
optimization moves the unbind-1 back to right after a varbind, right?
If so is optimization is indirectly equivalent to yours.

I can see one other case where Stefan's optimization might make a
difference.  If we install your tail-jumping optimization, Stefan's
optimization might produce more opportunities to do tail-jumping, or
it might ruin some opportunities to do tail-jumping.  But I think
that effect will be too small to matter anyway.

Unless I have missed some point here, I think your version of the
optimization is the better of the two (all else being equal), because
it gets directly to the desired result instead of requiring it to be
done in two steps.

Some comments on details of your code:

    +(put 't 'binding-is-magic t)
    +(put 'nil 'binding-is-magic t)

That is unnecessary; you can't bind nil or t,

    +(put 'debug-on-next-call 'binding-is-magic t)

That is unnecessary, since a function call would never
be safe to do this optimization over,

    +(defconst byte-compile-side-effect-free-dynamically-safe-ops
    +  '(;; Same as `byte-compile-side-effect-free-ops' but without
    +    ;; `byte-varref', `byte-symbol-value' and certain editing
    +    ;; primitives.

Why exclude byte-symbol-value?

After you deal with those little points, I'd like your code to be
installed.  However, there is still the question of whether we should
change the standard defsubst to work the way defsubst* does.