Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!MITCH.ENG.SUN.COM!wmb
From: wmb@MITCH.ENG.SUN.COM (Mitch Bradley)
Newsgroups: comp.lang.forth
Subject: Deoptimizers?
Message-ID: <9102100538.AA07885@ucbvax.Berkeley.EDU>
Date: 9 Feb 91 07:36:44 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: Mitch Bradley <wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV>
Organization: The Internet
Lines: 14

> If you can write optimizers, you can write deoptimizers.

True to a degree...  At some level, optimization involves loss of
information about the source text.  Simple optimizations like peephole
optimizations to remove redundant push/pop pairs are easy to "undo", but
code motion and common subexpression removal can be very difficult to
"deoptimize".

Of course, the stack tends to impose an ordering constraint that makes
the more "studly" optimizations somewhat impractical, compared to the
data flow optimizations that can be done for code generated to a register-
transfer model.

Mitch