Byte compiler inefficiency

Byte compiler inefficiency

[David Kastrup]

Hi, we have

(defsubst cadr (x)
  "Return the car of the cdr of X."
  (car (cdr x)))

And if we use that, for example, in

(defun woozle (blurb) (cadr blurb))

then the byte compiler delivers the result:

byte code for woozle:
  args: (blurb)
0	varref	  blurb
1	dup	  
2	varbind	  x
3	cdr	  
4	car	  
5	unbind	  1
6	return	  

The binding for x is completely unnecessary and wasteful.  FWIW, the
XEmacs byte compiler does not do this unnecessary binding.

I think that the byte compiler should be smart enough to remove
unnecessary bindings from defsubst stuff consisting purely of
side-effect free primitives and substitutions: those are not likely to
be advised, and if they are, one can still mark them as
non-side-effect free after the advice is activated.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Byte compiler inefficiency

[Richard M. Stallman]

    The binding for x is completely unnecessary and wasteful.

It is necessary in order for compiled code to do the same thing
as the interpreted code.  When cadr is called interpretively,
the binding of x is like any other binding.

Now, we could consider adopting the convention that it is ok for the
compiled code not to work just like the interpreted code in this
particular kind of case.

Re: Byte compiler inefficiency

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     The binding for x is completely unnecessary and wasteful.
>
> It is necessary in order for compiled code to do the same thing as
> the interpreted code.

No, unless by "same thing" you mean "equally inefficient" in which
case defsubst would need to be the same as defun.

> When cadr is called interpretively, the binding of x is like any
> other binding.

Sure, but the binding can't possible have any effect on the result.

> Now, we could consider adopting the convention that it is ok for the
> compiled code not to work just like the interpreted code in this
> particular kind of case.

We are talking about "defsubst" here.  There are no guarantees
whatsoever that redefining functions like "car" and "cdr" subsequently
(and that is the only way that the binding could possibly have an
effect) will reflect back onto previously compiled versions of the
defsubst definition.

There _is_ no difference to the interpreted code: the temporary
binding has no possible effect: even if "car" or "cdr" throw an error
for which an error handler has been installed, the binding will have
been unwound before the error handler gets called.  The only instance
that could possibly see a difference would be the debugger.

But again: if you are worried about complete equivalence, defsubst can
never do anything better than defun.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Byte compiler inefficiency

[Richard M. Stallman]

    > When cadr is called interpretively, the binding of x is like any
    > other binding.

    Sure, but the binding can't possible have any effect on the result.

In the particular case of cadr, it can't, because no non-primitive
functions are called.  If the compiler could detect this kind of case,
it could do the optimization safely.

However, if the defsubst calls some non-primitives, they could refer
to the variable, so failing to bind it would be unsafe.

Implementing the optimization in the former case would be useful,
and I will put it in etc/TODO, but it should not be done until
after the release.

Re: Byte compiler inefficiency

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     > When cadr is called interpretively, the binding of x is like
>     > any other binding.
>
>     Sure, but the binding can't possible have any effect on the
>     result.
>
> In the particular case of cadr, it can't, because no non-primitive
> functions are called.  If the compiler could detect this kind of
> case, it could do the optimization safely.
>
> However, if the defsubst calls some non-primitives, they could refer
> to the variable, so failing to bind it would be unsafe.

Probably it would make sense to put a property on functions that are
known not to depend on external bindings.  The byte compiler could
even propagate this property to functions like cadr.

> Implementing the optimization in the former case would be useful,
> and I will put it in etc/TODO, but it should not be done until after
> the release.

Thanks.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Byte compiler inefficiency

[Stefan Monnier]

> (defsubst cadr (x)
>   "Return the car of the cdr of X."
>   (car (cdr x)))

There has already been discussions of such issues on this list.  There are
various ways to make byte-opt.el get rid of the extra varbind.
I had a suggestion, but it's not robust against some improperly nested
byte-code (which can't currently be generated by the byte-compiler, but
could be generated by some other byte-compiler), and someone else had
another suggestion which didn't have such a shortcoming.  I thought his
suggestion had been installed but if you say the "problem" is still present,
it looks like it never got installed.


        Stefan