Re: Small LAP peephole optimization

[Dmitry Antipov <dmantipov@yandex.ru>]

Ken Raeburn wrote:

> Now if the author of "foo" isn't sure that "quux" is going to return a 
> numeric value, removing the addition changes the semantics of "foo".

Yes. I understand this myself after a short meditation around the comment
above 'byte-compile-associative' :-).

> I would guess that in most of these cases it's a safe optimization, but 
> you should really check.

What do you think about such 'unsafe' optimizations in general ? As I know,
some CL systems (such as from Franz) allows byte compiler to be very aggressive
at the cost of safety.

> If the previous operation is guaranteed to leave a numeric value at the top
 > of the stack, as in your example, and no other code can branch to the +0 sequence,
 > then you can do the optimization; otherwise, you probably shouldn't.

As I understand, branching to +0 is impossible if there is no TAG between
previous byteop an (byte-constant 0), so we might safely optimize the
sequences like

<numeric-on-top-op> (byte-constant 0) (byte-plus . 0) -> <numeric-on-top-op>

Less obvious cases are also interesting, but I'm not sure that saving 2 ops
might push someone to implement substantially more complex logic.

Dmitry