In this short video, I'm going to say a
few words about a variation on local
optimization that applies directly to
assembly code called Peephole
Optimization. The basic idea here is that
instead of optimizing on intermediate code
we could do our optimizations directly on
assembly code And people optimization is
one such technique. The peephole is,
stands for a short sequence of usually
continuous instructions. So, the idea is
that we have our program. We can see, we
can think of it as a long sequence of
instructions and our peephole is some
window onto this program. So, if we have a
peephole of size four, we can think of
ourselves as staring through a small hole
at the program and all we can see is a
short sequence of four instructions and
then we can optimize that sequence. So,
then we can slide the peephole around and
optimize different parts of the program
And the, what the, what the optimizer will
do is it will, you know, stare at this
short sequence of instructions and if it
knows a better sequence it will replace
that sequence by the other one and then it
will repeat this as I said. You know,
applying other transformations to, to
possibly the same or other parts of the
assembly program. So, people optimizations
are generally written as replacement
rules. So, the we'll have the window of
instructions on the left. So, it'll be
some sequence of instructions and we'll
know some other sequence of instructions
that we would prefer on the right. So, if
we see this instruction sequence on the
left, then we'll replace by the one on the
right-hand side. So, for example, if I
have a move from register b to register a
and then I move back from register a to
register b well, that's the second move is
useless, can, can just be deleted as a way
to replace this two instruction sequence
by a one instruction, instruction
sequence. And this will work provided that
there's no possible jump target here. So
if, if there's no possibility that the
code would ever jump to this instruction
then that instruction can be removed.
Another example, If I add i to the
register a, and then I subsequently add j
to the register a, I can do a constant
folding optimization here, and combine
those two add two additions into one
addition where I add the sum of i = j to
the register A. So, many but not quite all
of the basic block optimizations that
we've discussed in the last video, can be
cast also as peephole optimizations. So,
for example if we are adding zero to a
register and we're storing it in another
register, well, that can be replaced by a
register move. If we're moving a value
from the same register to itself so this
is like a self-assignment, well, that
instruction can just be deleted, replaced
by the empty sequence of instructions. And
together for those two instructions would
be those two optimizations, excuse me,
would be able to eliminate adding zero to
a register. So, first this would get
translated into a move from a to a. And
then the move from a to a would get
deleted. And as this little example
illustrates just like with local
optimizations, people optimizations have
to be applied repeatedly to get the
maximum effect. I hope this simple
discussion has illustrated for you that
many optimizations can be applied directly
to assembly code and that there's really
nothing magic about optimizing
intermediate code. So, if you have a
program written in any language, source
language, intermediate language, assembly
language. It makes sense to talk about
doing transformations of programs written
in that language to improve the behavior
of the program. And it's also a good time
here to mention that program optimization
is really a terrible term. The compilers
do not produce optimal code and it's
purely an accident if a compiler were to
somehow generate the best possible code
for a given program. Really, what
compilers do is they have a bunch of
transformations that they know will
improve the behavior of the program. And
they'll just improve it as much as they ca
N. So, really what program optimization is
all about is program improvement. We're
trying to make the program better but
there's no guarantee that we will reads
the best possible code for a given