[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 1.5.0.7 (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
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