[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Small LAP peephole optimization

From: Dmitry Antipov
Subject: Re: Small LAP peephole optimization
Date: Thu, 10 May 2007 18:21:07 +0400
User-agent: Thunderbird (X11/20061008)

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 
> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]